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Section  1.  CDL  Processor 


1.1  Purpose 

Existing  methods  of  managing  large  computational  configurations  (flows) 
lack  the  primary  ingredient  of  flexibility.  Generally,  computational  flow 
direction  is  "hard-wired"  within  the  program  body,  and  although  the  flow 
may  be  controlled  by  the  user  (via  input  options,  etc.),  unused  paths  for 
some  given  configuration  must  be  included  in  the  total  program  environment, 
thus  increasing  core  requirements.  Furthermore,  modifying  paths,  deleting 
old  ones,  and  introducing  new  ones  usually  require  extensive  changes. 

As  an  alternative  to  this  "standard  operating  procedure",  the  Config- 
uration Description  Language  (CDL)  allows  total  control  of  the  program 
flow  external  to  the  actual  program  environment.  CDL  permits  the  referencing 
of  program  units  at  the  "sub-executive"  level  (the  CDL  is  the  executive) 
and  thus  requires  that  the  program  be  designed  such  that  sub-executives 
represent  the  smallest  unit  of  execution  flow  control.  With  the  exception 
of  data  interfaces,  sub-executives  can  be  designed  without  regard  to  their 
position  in  the  program  flow.  With  CDL,  program  flows  can  be  designed 
easily,  and  even  some  basic  logic  control  structures  can  be  incorporated 
into  the  configurations. 

The  Configuration  Description  Language  Processor  is  a translator  which 
accepts  as  input,  a desired  program  flow,  and  generates  a top  level  executive, 
to  be  combined  with  the  actual  program  system.  The  generated  executive  is 
in  the  same  source  language  as  the  actual  program  system. 

The  CDL  Processor  is  designed  to  operate  either  independently,  or  in 
conjunction  with  a general  purpose  input  preprocessor  (see  reference  1). 

The  combined  system  could  be  applied  to  almost  any  program  system  requiring 
input  processing  and  external  control  of  program  flow. 

The  term  "configuration  control",  used  within  this  report,  refers  to 
the  ability  to  control  the  collection  of  modules,  and  the  order  in  which 
they  execute  for  a given  program  system.  It  is  not  to  be  confused  with 
the  well-known  configuration  management  definition. 

In  addition  to  providing  unique  input  capabilities  for  the  user,  the 
CDL  Processor  provides  the  programmer  with  several  facilities  to  aid  in 
the  maintenance  of  the  program  system.  The  programmer  defines  the  "sub- 
executive" environment,  thus  dictating  what  sections  of  the  program  can 
and  cannot  be  referenced  in  the  CDL.  The  management  of  program  data  files, 
library  files,  etc.  is  provided  through  input  specifications  and  BEGIN/ 

REVERT  procedures  that  are  automatically  generated. 

These  procedures  are  unique  to  the  SCOPE  3.4  operating  system  for  the  CDC 
6000  series. 


For  large  program  systems,  the  processor  can  optlonal.ly  generate 
directives  or  procedures  to  cause  the  program  system  to  be  segmented  or 
overlayed;  facilities  also  unique  to  SCOPE  3.4  (see  reference  2). 


The  CDL  Processor  is  implemented  in  SIMSCRIPT  II. 5 version  4.0  and  is 
intended  for  use  on  the  CDC  6700  system  under  SCOPE  3.4.  A knowledge  of 
CDC  nomenclature  is  assumed. 

1.2  Objectives 

Knowing  that  the  techniques  of  the  past  would  be  inadequate  in  pro- 
viding the  configuration  control  capabilities  required  by  the  TRICS  fire 
control  program,  the  problem  had  to  be  approached  from  a different  point 
of  view.  Therefore,  three  objectives  were  defined. 

The  first  objective  was  to  develop  a simple,  easy  to  use  language  for 
describing  program  configurations.  Other  means  of  describing  a program 
flow  or  configuration  through  input  were  considered  such  as  connectivity 
relationships;  for  example,  module  A connects  to  module  B.  However,  these 
were  quickly  ruled  out  because  they  would  not  provide  the  full  capabilities 
of  configuration  control  required.  Furthermore,  since  a configuration  is  a 
program  flow,  the  most  logical  way  of  describing  the  flow  is  through  a high 
level  language.  By  adhering  to  the  basic  structures  of  a standard  program 
design  language  (PDL) , the  language  would  be  more  familiar  to  a greater 
number  of  people. 

The  second  objective  was  not  only  to  consider  the  needs  of  the  user 
but  also  the  programmer  by  developing  procedures  whereby  maintenance  of 
the  program  system  utilizing  CDL  would  be  reduced.  This  involved  elevating 
many  of  the  activities  normally  performed  internally  at  the  program  level, 
to  a high  level  external  environment.  In  essence,  the  objective  was  to 
eliminate  program  changes  for  new  or  different  configurations. 

Finally,  design  the  system  as  table-driven  for  "off-the-shelf"  use. 
Knov’ing  that  the  Advanced  Weapon  System  Simulation  (AWSS)  program  would 
have  the  same  requirements  of  configuration  control  as  TRICS,  the  objective 
was  to  insure  that  the  system  could  be  easily  adapted  to  AWSS,  as  well  as 
other  programs  requiring  configuration  control. 

1.3  Language  Specifications 

The  CDL  allows  the  designer  of  a configuration  to  control  the  sequence 
in  which  computational  modules  are  executed.  The  language  provides  immedi- 
ate documentation  and  encourages  a structured  approach  to  designing  config- 
urations. 
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Configuration  level  modules  specified  in  the  CDL  map  into  sub-executives 
with  regard  to  the  internal  structure  of  the  program.  To  add  flexibility 
to  the  CDL,  various  types  of  sub-executives  can  be  defined.  The  following 
sub-executive  types  are  supported: 


a.  "PHASE"  sub-executives  mark  the  beginning  of  a major  section  in 
the  system 


b.  "COMPUTES"  sub-executives  perform  computations  only 


c.  "MACRO"  sub-executives  symbolize  some  expanded,  predefined  CDL 


d.  "DECISION"  sub-executives  are  used  for  decision  making  in  the  CDL 


Sub-executive  names  specified  in  the  CDL  can  be  up  to  thirty  (30) 
characters  in  length,  the  first  10  of  which  must  be  unique. 


The  Configuration  Description  Language  (CDL)  is  simple,  easy  to  learn, 
and  provides  all  the  capabilities  for  describing  a configuration.  Although 
CDL  input  is  in  free  format,  indentation  is  encouraged  to  emphasize  structure. 
The  only  requirement  is  that  at  least  1 blank  appear  between  fields.  In 
the  description  below,  brackets  (f})  refer  to  optional  keywords  and  slash  (/) 
means  "or". 


The  first  CDL  structure  provides  a means  of  defining  a major  phase  of 
the  CDL.  It  signifies  that  all  modules  referenced  up  to  the  next  phase 
definition  are  part  of  this  phase.  Its  format  is: 


START  phase 


For  example: 


START  PATROL 


Only  "PHASE"  sub-executives  can  be  referenced  with  START. 


Computational,  or  macro  type  sub-executives  can  be  initiated  with  the 
RUN  command. 


RUN  modules 


For  example: 


RUN  JOE 


More  than  one  module  can  be  Included  on  a RUN  statement,  e.g. , 

RUN  JOE  TOM 

Uhen  a macro  sub-executive  Is  referenced,  the  CDL  Processor  will 
substitute  the  predefx. 3d  CDL  for  this  macro  and  begin  processing. 

In  the  following  example: 

START  A 

RUN  JOE  TOM 
START  B 

RUN  FRED  JOHN 

the  modules  JOE  and  TOM  belong  to  phase  A while  FRED  and  JOHN  belong  to 
phase  B. 

The  IF  statement  Is  used  to  determine  whether  a specified  decision 
module  Is  true  or  false  when  Invoked,  or  to  test  program  variables.  Control 
continues  with  the  succeeding  statements  for  the  true  condition  and  trans- 
fers to  the  corresponding  ELSE  statement  for  the  false  condition.  The 
ENDIF  statement  marks  the  point  where  the  two  paths  meet. 

IF  condition  ff IS}  TRUE/FALSE}  fTHEN} 

where  "condition"  is  a decision  module  (sub-executive)  or  a logical  ex- 
pression; for  example, 

IF  TIME  < 10.0 

Either  variables  global  to  the  system  or  constants  can  be  tested  and  up  to 
thirty  (30)  characters  can  be  used  for  each  expression  (no  imbedded  blanks). 
This  implies  that  a statement  such  as 

IF  TIME+3*X  < A 

is  legal. 

Relational  operators  available  are: 

< less  than 

> greater  than 

>=  greater  than  or  equal  to 

= equal  to 

<?*  less  than  or  equal  to 

A=  not  equal  to 
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"IF"  st'tements  can  be  nested  as  desired  and  the  "true"  condition  is 
assumed  as  default.  They  can  be  of  the  form  "IF  THEN”  or  "IF  THEN  ELSE". 

In  any  case,  the  IF  must  be  terminated  by  an  ENDIF.  For  example; 

IF  A IS  TRUE  THEN 
RUN  B 

ELSE 

RUN  C 

ENDIF 
RUN  D 

An  attempt  to  reference  sub-executive  types  other  than  "decision"  will 
result  in  an  error  message. 

The  DO  WHILE  clause  is  used  to  control  iterations  as  long  as  the 
specified  condition  is  true  (default)  or  false. 

DO  WHILE  condition  fflS}  TRUE/FALSE} 

where  "condition"  is  the  same  as  with  IF  statements.  An  ENDDO  designates 
the  end  of  a segment  to  be  executed  repeatedly.  For  example: 

DO  WHILE  Z IS  FALSE 
RUN  X 
RUN  Y 

ENDDO 

The  decision  module  is  invoked,  or  the  variables  are  tested  at  the 
beginning  of  the  loop.  DO  WHILE  statements  can  be  nested  as  desired  and 
IF  statements  can  be  included  within  a DO  WHILE  segment. 

A variation  of  the  DO  WHILE  statement  is  the  DO  FOR  statement.  It 
allows  the  user  to  specify  how  many  times  a segment  is  to  be  repeated. 

DO  FOR  I - A TO  B 

where  I is  either  a user-defined  variable  or  a predefined  program  monitored 
variable.  A monitored  variable  implies  that  the  executive  controller  will 
maintain  the  current  value  of  the  variable  as  the  loop  progresses,  as  well 
as  invoke  a predefined  monitored  routine  at  the  beginning  of  the  loop.  A 
and  B are  either  integer  constants  or  integer  variables.  For  example: 

DO  FOR  I = 1 TO  NMSLS 


RUN  A B C 

ENDDO 


For  unconditional  branching  to  a specified  label,  the  GO  TO  statement 
is  provided. 


GO  TO  label 


A statement  label  identifies  a transfer  point  for  a GO  TO  statement 
and  can  appear  anywhere  in  the  CDL.  A label  can  be  any  combination  of  up 
to  8 nonblank  characters  enclosed  in  apostrophes.  For  example: 


' PERFORM' 


'10.3' 


'ERROR. 10' 


Comments  are  also  allowed  in  the  CDL  and  are  always  preceded  by  two 
apostrophes  (i.e.,  ").  When  these  two  characters  are  encountered  in  the 
input  text,  the  remainder  of  the  card  image  is  assumed  to  be  comment  text. 


The  TEXT  feature  of  CDL  allows  the  specification  of  card  images  to 
be  included  in  the  generated  executive.  The  card  images  are  not  modified 
by  the  CDL  processor  and  will  appear  in  the  same  relative  position  in  the 
executive  as  the  CDL.  The  TEXT  feature  is  a convenient  way  of  manually 
inserting  code  in  the  executive.  The  format  is: 


card  images 


ENDTEXT 


Individual  card  images  can  be  specified  as  text  by  placing  an  ampersand 
(&)  in  column  1.  In  this  case,  the  card  image  is  shifted  1 column  to  the 
left  when  included  in  the  generated  executive.  This  is  necessary  to  allow 
FORTRAN  comments  to  be  specified  in  this  manner. 


When  inserting  code  with  the  TEXT  feature,  the  user  should  consider 
the  impact  on  the  global  data  environment.  Also,  caution  should  be  exer- 
cised when  inserting  code  that  would  affect  the  flow  of  the  executive. 


All  configurations  must  be  terminated  by  an  "END"  statement,  e.g.. 


START  A 
DO  WHILE  Z 
RUN  X 
RUN  Y 
ENDDO 
END 
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Section  2.  CDL  Processor  Design  Concepts 


2.1  General  Description 

The  CDL  Processor  accepts  as  input,  a CDL  specifying  a particular 
computational  flow.  The  primary  function  is  to  translate  the  CDL  into 
some  desired  target  source  language  which  is  the  same  as  the  language 
used  in  implementing  the  program  computations.  The  translated  CDL  is  now 
the  executive  (or  driver)  which  can  be  compiled  and  linked  with  the  sub- 
executives referenced  in  the  original  CDL  (see  figure  1).  By  defining  the 
entire  system  as  a library,  only  those  modules  referenced  or  required  by 
the  sub-executives  need  to  be  loaded. 

Translating  the  CDL  to  the  target  source  language  is  a two-step  pro- 
cess. First,  the  processor  builds  what  is  called  the  FLOW  vector  from 
the  original  CDL  source.  The  FLOW  vector  contains:  a)  pointers  to  data 
which  are  essential  in  the  translation;  and  b)  branching  information  re- 
flecting the  flow  of  the  resulting  program.  Second,  the  FLOW  vector  is 
translated  to  the  target  source  language.  This  is  a relatively  simple 
process  since  the  FLOW  vector  contains  the  information  essential  in  build- 
ing the  logic  of  the  resulting  program.  The  translated  source  code  gener- 
ally consists  of  a main  program  and  an  executive  controller  which  is  called 
by  the  main  program. 

There  are  three  global  variables  which  must  be  manipulated  by  the 
sub-executives.  These  variables  are  ERRTYP,  ERRNO,  and  LRESLT  and  are 
used  in  error  detection  code,  and  code  generated  for  decision-type  sub- 
executives. ERRTYP  denotes  whether  the  detected  error  is  fatal  or  non- 
fatal  and  must  be  set  to  one  of  the  following  hollerith  strings:  "FATAL", 
or  "NONFTL".  The  number  of  the  error  detected  is  stored  in  ERRNO. 
Decision-type  subexecutives  must  return  a logical  value.  This  is  simulated 
by  storing  a 0 in  LRESLT  for  false  or  a 1 in  LRESLT  for  a true  result. 

2.2  CDL  Specification 

The  CDL  processor  is  capable  of  operating  in  conjunction  with  an 
input  preprocessor  (see  reference  1).  The  input  preprocessor  (INPUTP)  is 
capable  of  handling  a default  file  and  a file  of  override  data.  The  CDL 
is  always  specified  on  the  override  data  file. 

The  CDL  specification  can  reference  a predefined  CDL  on  a separate 
file  (USE),  a CDL  from  the  previous  case  (PREVIOUS),  no  CDL  (NONE),  or  a 
CDL  can  be  created  in  the  override  data  (CREATE). 

Since  the  CDL  processor  and  input  preprocessor  are  two  separate  pro- 
grams, the  CDL  processor  is  responsible  for  separating  the  CDL  specifications 
and  the  normal  override  data  into  two  "created"  files.  This  gives  the  user 
the  ability  to  specify  all  override  data  on  one  file  in  addition  to  alle- 
viating the  input  preprocessor  of  having  to  sift  through  CDL  specifications. 
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Hence,  on  the  first  case,  the  CDL  processor  creates  two  files,  one  con- 
taining the  CDL  specifications,  the  other  containing  the  override  data. 

The  CDL  processor  then  reads  from  the  created  file.  The  input  preprocessor 
always  reads  from  the  created  file,  if  one  was  created. 

2.3  Initializing  the  CDL 

The  CDL  processor  is  essentially  table-driven  in  that  all  sub-executive 
names  and  their  types  are  defined  externally  on  an  initialization  or 
"template"  file.  This  file  also  contains  other  information  required  to 
translate  the  CDL  to  some  target  source  language.  It  is  intended  to  be  a 
programmer-maintained  file  since  it  defines  the  program  environment. 

Other  information  on  this  file  includes  the  name  of  the  resulting 
main  program,  the  name  of  the  subroutine  executive  controller,  monitored 
variables  and  their  routines,  macro  expansions  for  sub-executives  of  that 
type,  frontend  routines  and  rearend  routines  to  be  called  before  and  after 
the  executive  controller,  files  associated  with  the  models,  relational 
operators  used  in  translating,  FORTRAN  common  blocks  (if  the  target  language 
is  FORTRAN)  required  by  the  executive  controller,  and  a list  of  all  common 
blocks  required  for  automatic  program  segmentation  (see  reference  2).  The 
relational  operators  include  not  >only  those  used  in  the  CDL  but  also  the 
target  language  equivalent.  For  example,  "<?'  would  map  into  ".LT."  for 
FORTRAN. 

Keywords  are  used  to  designate  the  varous  types  of  data  on  this  file. 
Keywords  must  begin  in  column  1 while  all  other  data  begins  beyond  column 
1 in  free  format.  The  layout  of  this  file  and  an  example  is  given  in 
Appendix  A. 

Keywords  and  their  associated  data  can  usually  be  specified  in  any 
order,  however,  there  are  some  restrictions.  Data  describing  the  sub- 
executives to  be  referenced  must  be  defined  before  macro  expansions, 
model  and  file  definitions,  and  frontend  and  rearend  routines.  This  is 
necessary  since  data  structures  created  at  the  time  this  keyword  is  processed 
are  used  for  processing  other  keywords.  Model  and  file  definitions  should 
be  defined  before  frontend  and  rearend  routines  for  the  same  reason.  Main 
program  commons,  executive  controller  commons,  loader  directives,  and 
segment  commons  must  be  given  in  that  order  and  after  all  other  data  on 
the  initialization  file.  This  is  required  since  the  processor  does  not 
store  this  data  but  merely  copies  the  card  images  up  to  the  next  keyword 
when  appropriate. 


2.4  Basic  Data  Structures  and  Table  Representation 

When  processing  the  CDL,  it  is  necessary  to  search  several  different 
tables  to  determine  what  should  be  stored  in  the  FLOW  vector.  These  tables 
are  either  represented  by  or  linked  to  one  common  data  structure  so  that 
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the  same  searching  mechanism  can  be  used  for  table  lookup.  6ince  the  CDL 
processor  is  implemented  in  SIM5CRXPT  II. 5,  all  data  structures  are  defined 
with  SIMSCRIPT  syntax. 


Basically,  table  entries  are  represented  by  temporary  entities  filed 
in  a set,  where  a set  exists  for  each  table  class.  The  basic  data  structures 
are  defined  as  follows: 


EVERY  CLASS  OWNS  AN  INPUT. LIST 


EVERY  PARAM  HAS 
A PNAME, 

A PNAME 1, 

A (PI VALUE, PA VALUE) 
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A PTYPE, 

A PMDL.REF, 

A PMDL.TYPE, 

A PMDL. ENTITY, 

A POVERLAY, 

AND  BELONGS  TO  AN  INPUT. LIST 
AND  MAY  BELONG  TO  THE  SBX.LIST 


A CLASS  entity  exists  for  each  table  defined. 

The  attributes  of  the  PARAM  entity  are  used  differently  for  each 
table  type  and  are  defined  for  each  table  type  described  below. 


PARAM  entities  are  also  used  for  storing  intermediate  data  associated 
with  the  FLOW  vector. 


2.4.1  Table  Environment 

As  the  CDL  Processor  scans  the  given  CDL,  it  must  search  appropriate 
tables  to  determine  what  actions  are  to  be  taken  and  what  data  structure 
pointers  are  to  be  stored  in  the  FLOW  vector.  For  example,  when  scanning 
a statement  such  as: 

RUN  A 

the  processor  must  search  the  list  of  keywords  to  determine  that  the  "RUN" 
keyword  processor  must  be  invoked.  Next,  the  list  of  sub -executives  must 
be  searched  to  get  the  PARAM  entity  created  for  the  sub-executive  A,  and 
then  the  entity  is  stored  in  the  FLOW  vector. 
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2.4. 1.1  Externally  Defined  Tables 

To  process  a CDL,  it  is  necessary  to  know  the  namesoof  all  sub-executives 
to  be  referenced  in  the  CDL.  Sub-executives,  their  types,  routine  names. 
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and  their  associated  models  are  defined  on  the  initialization  file. 

Every  sub-executive  is  represented  by  a "PARAM1  entity  with  the 
attributes  defined  as  follows: 

PNAME  * pointer  to  the  sub-executive  name 

PNAME1  ■ first  10  characters  of  the  name 

PAVALUE  ■ corresponding  routine  name  (or  MACRO  entity  for  PTYPE  * 

MACRO,  see  below) 

PTYPE  ■ type  of  sub-executive:  phase,  decision,  computational, 

or  macro 

PMDL.REF  = pointer  to  the  name  of  the  model  with  which  it  is 
associated 

PMDL.TYPE  ■ denotes  whether  this  entry  is  a model  or  not 
■ blank,  not  a model 
= MODEL,  entry  is  a model 

PMDL.PTR  - pointer  to  the  MODEL  entity  if  PMDL.TYPE  - MODEL 

POVERLAY  ■ overlay  number  for  this  sub-executive  assigned  by  the 
CDL  Processor 

For  "macro"  type  sub-executives,  a CDL  expansion  is  implied.  The 
macro  expansions  are  also  part  of  the  initialization  file  and  are  repre- 
sented as: 

EVERY  MACRO  OWNS  A MA. EXPANSION 

EVERY  CDL. STATEMENT  HAS 
A CARD. IMAGE, 

AND  BELONGS  TO  A MA. EXPANSION 

The  MACRO  temporary  entities  are  stored  in  the  PARAM  temporary  entity  so 
that  the  expansion  can  be  easily  retrieved  and  processed  when  macro-type 
sub-executives  are  referenced.  MACRO  sub-executives  may  be  specified 
within  a MACRO  expansion  thus  allowing  multi-level  expansions. 

Models  and  their  associated  files  are  specified  so  that  the  proper 
file  environment  can  be  defined  prior  to  execution.  Associated  with  each 
model  are  libraries,  relocatable  block  data  files,  local  files,  data  files, 
input  preprocessor  initialization  (IPI)  files,  and  the  default  data  file. 
Local  files  refer  to  all  file  names  which  must  be  included  on  the  PROGRAM 
card  for  CDC  FORTRAN  EXTENDED  programs  (includes  the  LFN  for  all  data  files 
as  well). 

Since  these  files  are  included  in  a generated  BEGIN/REVERT  procedure 
(optional)  for  executing  the  model(s),  linked  lists  must  be  defined  for 
easy  retrieval.  When  models,  or  sub-executives  of  a particular  model  are 
specified  in  the  CDL,  the  data  structures  for  the  model  are  saved  in  an- 
other list.  When  the  CDL  is  processed,  files  for  each  model  are  retrieved 
for  those  models  in  the  CDL.  These  files  can  be  overridden  through  the 
the  override  input.  The  required  data  structures  are  given  below. 
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EVERY  MODEL  HAS 
A MDL. NAME , 

A MNAME1, 

AND  OWNS  A MDL. LIB. LIST, 

MDL. BLK. LIST, 

MDL. PLO. LIST, 

MDL. EXT. LIST, 

MDL. IPI. LIST, 

MDL. DEF. LIST, 

MDL. FE. LIST, 

MDL. RE. LIST, 

AND  BELONGS  TO  THE  MDL. COL. LIST 

EVERY  LIB. FILE  HAS 
A LIB.PFN, 

A LIB. USERID, 

A LIB.LFN, 

A LIB. CYCLE 
AND  BELONGS  TO  A MDL. LIB. LIST 

EVERY  BLK. FILE  HAS 
A BLK.PFN, 

A BLK. USERID, 

A BLK. CYCLE 

AND  BELONGS  TO  A MDL. BLK. LIST 

EVERY  PL0.FILE  HAS 
A PL0.LFN, 

A PL0. BUFSIZE, 

A PL0.EQ, 

AND  BELONGS  TO  A MDL. PL0. LIST 
AND  BELONGS  TO  THE  PGM. CRD. LIST 

EVERY  EXT. FILE  HAS 
AN  EXT.LFN, 

AN  EXT.PFN, 

AN  EXT. USERID, 

AN  EXT. CYCLE 

AND  BELONGS  TO  A MDL. EXT. LIST 

EVERY  IPI. FILE  HAS 
AN  IPI.PFN, 

AN  IPI. USERID, 

AN  IPI. CYCLE 

AND  BELONGS  TO  A MDL. IPI. LIST 
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EVERY  DEF.FILE  HAS 
A DEF.PFN, 

A DEF. USERID, 

A DEF. CYCLE 

AND  BELONGS  TO  A MDL. DEF. LIST 

EVERY  SPGM  HAS 

A SPGM. NAME 
AND  MAY  BELONG  TO 
A MDL. FE. LIST 
A MDL. RE. LIST 
A PGM. LIST 

Model  entitles  are  created  for  each  model  specified  on  the  CDL 
Initialization  file  and  are  stored  In  the  PMDL. ENTITY  attribute  of  the 
PARAM  entity  created  for  the  model. 

When  the  "MODEL"  keyword  is  encountered  in  the  initialization  file, 
it  is  necessary  to  search  the  list  of  sub-executives  to  determine  if  a 
PARAM  entity  exists  for  a model.  It  is  necessary  to  explicitly  define  a 
model  as  a sub-executive ; however  the  model  can  be  any  sub-executive  type 
desired. 

Files  that  are  global  to  the  system  can  be  defined  by  specifying 
"GLOBAL"  as  the  model  name  followed  by  the  global  files.  In  this  case, 
PARAM  and  MODEL  entities  are  created  to  represent  the  global  model*  The 
PARAM  entity  is  filed  in  the  INPUT. LIST  set  for  sub-executives  with  the 
PMDL. ENTITY  attribute  defined  as  the  MODEL  entity. 

Monitored  variables  referenced  in  the  CDL  on  a "DO  FOR"  statement  are 
defined  on  the  initialization  file.  The  associated  monitored  routine  name 
must  also  be  included  for  each  variable.  The  PARAM  entity  attributes  for 
monitored  variables  are  defined  as: 

PNAME  = pointer  to  the  monitored  variable  name 

PAVALUE  = monitored  routine  name 

Frontend  or  rearend  routines  can  be  either  global  or  model-specific 
and  are  represented  by  SPGM  entities  where  SPGM. NAME  contains  the  name  of 
the  routine.  The  SPGM  entities  are  filed  in  the  MDL. FE. LIST  set  for  front- 
end  routines,  or  the  MDL. RE. LIST  set  for  rearend  routines  referenced  by 
the  global  MODEL  entity  or  the  specific  MODEL  entity. 

Logical  operators  and  their  target  source  language  equivalent  are 
also  part  of  the  initialization  file  and  are  represented  by  PARAM  entities: 

PNAME  = pointer  to  the  logical  operator  symbol(s) 

PAVALUE  ■ target  source  language  equivalent 
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2.4. 1.2  Internally  l'efined  Tables 

Keyvords  for  the  CDL  Initialization  file  are  defined  in  a table 
Internally.  The  attributes  of  the  PARAM  entity  are  defined  as  follows: 

PNAME  - pointer  to  the  keyword  name 
PA VALUE  “ keyword  index  number 

The  keywords  currently  available  are: 

1.  SUB-EXECS 

2.  MACROS 

3.  MONITORED 

4.  MODELFILES 

5.  FRONTEND 

6.  REAREND 

7.  OPERATORS 

8.  LANGUAGE 

9.  PROGRAM 

10.  CONTROLLER 
11  i COMMONS 

12.  SEGMENT 

13.  EXEC 

14.  LOADER 

15.  RECOVERY 

CDL  keywords  are  defined  internally,  again  by  PARAM  entities.  Each 
keyword  has  an  associated  keyword  routine.  Attributes  of  the  PARAM  entity 
are  defined  as  follows: 

PNAME  ■ pointer  to  the  keyword  name 

PIVALUE  ■ subprogram  variable  for  the  keyword  routine 

The  following  is  a list  of  CDL  keywords  currently  supported: 


Keyword 

RUN 

IF 

ELSE 

ENDIF 

DO 

ENDDO 

START 

&C0MMENT& 

&LABEL& 

TEXT 

GO 

END 

ENDTEXT 


Associated  Subprogram 


RUN. KEYWORD 
IF. KEYWORD 
ELSE. KEYWORD 
ENDIF. KEYWORD 
DO. KEYWORD 
ENDDO. KEYWORD 
START. KEYWORD 
COMMENT. KEYWORD 
LABEL. KEYWORD 
TEXT. KEYWORD 
GO. TO. KEYWORD 
END.  KEYWORD 
TEXT. KEYWORD 
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The  keywords  COMMENT  and  LABEL  are  preceded  by  the  symbol  "&"  to 
denote  that  they  are  detected  by  special  symbols  in  the  CDL  text  rather 
than  the  names  given. 

FILE  keywords  represent  those  keywords  available  for  file  specifi- 
cations on  the  initialization  file,  or  for  overriding  files  given  on  the 
initialization  file  (see  section  2.6.2).  A PARAM  entity  is  created  for 
each  keyword  and  files  in  the  INPUT. LIST  set  for  file  keywords.  The  file 
keywords  currently  available  are: 

1.  LIBRARY 

2.  BLOCK. DATA 

3.  LOCAL 

4.  DATA 

5.  IPI 

6.  DEF 

2.5  CDL  Runtime  Options 

There  are  four  runtime  options  for  the  CDL  Processor  which  are 
specified  through  the  PARM  feature  of  SIMSCRIPT.  The  options  are  included 
on  the  "execute"  card  primarily  for  convenience.  The  four  options  are: 

LOAD  ” Option  for  loading 

"0VL"  perform  overlay  loading 

"SEG"  perform  SEGLOAD,  i.e.,  generate  segment  loader  directives 
"NORM"  perform  normal  loading  (default) 

MACRO  ” Macro  expansion  printout  option 

"YES"  for  macro  expansion  printout, 

"NO"  for  no  macro  expansion  printout  (default) 

JCL  ■ Generate  BEGIN/REVERT  procedure  option 
"YES"  to  generate  procedures 
"NO"  to  suppress  the  generation  (default) 

LC  * last  column  for  all  input  to  the  CDL  Processor  (default  is  72) 

2.6  Override  Input 
2.6.1  CDL  Specification 

CDL  specifications  can  only  appear  in  the  override  input,  and  can  be 
given  in  any  order.  There  are  four  CDL  specification  options  available: 
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1.  USE 

2.  CREATE 

3.  PREVIOUS 

4.  NONE 

USE  implies  that  a CDL  from  a file  containing  a catalog  of  CDL's  will 
be  used.  This  file  must  have  CDL's  defined  as  follows: 

CDL  name  1 

(CDL  specifications) 


END 

CDL  name  2 

(CDL  specifications) 


where  the  CDL  keyword  begins  in  column  1.  To  retrieve  a CDL  from  the  file, 
one  would  include  in  the  override  input: 

CDL 

USE  name 

and  the  CDL  keyword  must  begin  in  column  1. 

CREATE  means  that  CDL  specifications  will  be  included  in  the  override 
input,  for  example, 

CDL 

CREATE 
RUN  A 
RUN  B 
END 

The  keyword  PREVIOUS  following  CDL  in  the  override  input  means  use 
the  CDL  from  the  previous  case.  This - condition  is  default  on  the  second 
and  succeeding  cases  and  it  cannot  be  specified  on  the  first  case. 

If  no  CDL  is  required,  then  the  keyword  NONE  must  be  specified. 

2.6.2  File  Override  Data 

Although  the  file  environment  for  each  model  is  defined  on  the  CDL 
initialization  file,  it  is  sometimes  desirable  to  change  some  of  these 
files.  Libraries,  relocatable  block  data  routine  files,  data  files,  IPI, 
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local,  and  default  files  for  any  model  can  be  overridden  through  specifi- 
cations on  the  override  input  file.  To  do  this,  the  FILES  keyword  is 
required  (beginning  in  column  1 of  course)  followed  by  the  model  name,  and 
the  files  to  add  or  delete.  The  general  form  is  as  follows: 

FILES 

model  name 

action  type  PFN  LFN  user  identification  cycle  number 
END 


where  "action"  is  ADD  or  DELETE,  "type"  is  LIBRARY,  BLOCK. DATA,  DATA,  IPI, 
LOCAL,  or  DEF,  "PFN"  is  the  permanent  file  name,  "LFN"  is  the  local  file 
name  (specified  for  DATA,  LIBRARY,  and  LOCAL  files  only).  PFN  and  user 
identification  are  not  specified  for  LOCAL  type  files. 

To  change  this  environment  internally,  the  INPUT. LIST  set  for  models 
is  searched  for  the  given  model.  When  found,  files  are  either  added  by 
creating  a file  entity  (LIB. FILE,  BLK.FILE,  PLO.FILE,  EXT. FILE,  IPI.FILE, 
or  DEF. FILE)  and  filing  in  the  appropriate  set,  or  removing  entitles  when 
files  are  deleted. 

2.7  Summary  of  Files  Associated  With  the  CDL  Processor 

The  following  table  describes  the  Input/output  files  associated  with 
the  CDL  processor. 

Unit 


Number 

Type 

Description 

SIMU2 

OUTPUT 

Dummy  output  file 

SLMU3 

OUTPUT 

Created  INPUTP  override  input  file 

SIMU5 

INPUT 

Original  override  input  file 

SIMU6 

OUTPUT 

Standard  output  file 

SIMU31 

INPUT 

CDL  initialization  file 

SIMU33 

INPUT 

File  of  predefined  CDL's 

SIMU35 

INPUT/OUTPUT 

Created  CDL  override  input  file 

SIMU37 

OUTPUT 

BEGIN/REVERT  procedure  file 

SIMU39 

OUTPUT 

Generated  main  program  and  executive 
controller  (in  the  target  source 
language) 

SIMU41 

OUTPUT 

Segment  directives  file 
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Section  3.  Translating  the  CDL  to  High  Level  Source  Code 


3.1  FLOW  Vector  Generation 

The  phase  of  the  CDL  processor  that  translates  the  CDL  to  the  FLOW 
vector  works  using  the  stack  principle.  Control  structures  such  as  IF 
and  DO  are  placed  on  the  stack  to  allow  nested  structures  and  also  for 
storing  information  about  the  structure  which  is  eventually  transferred 
to  the  FLOW  vector.  Also,  the  stack  principle  simplifies  the  verification 
of  the  structure  syntax. 

The  data  structure  used  to  represent  the  stack  and  its  entries  is  as 
follows: 


EVERY  STRUCTURE  HAS 
A STR.NAME, 

A STR. ENTITY, 

AND  BELONGS  TO  THE  STR. STACK 
DEFINE  STR. STACK  AS  A LIFO  SET 

STR.NAME  is  the  name  of  the  structure  (IF  or  DO),  STR. ENTITY  points  to  a 
temporary  entity  containing  information  about  the  structure  and  its  re- 
lation to  the  FLOW  vector,  and  STR. STACK  is  a LIFO  (Last  In,  First  Out) 
set  representing  the  stack. 

The  translation  phase  involves  reading  tokens  from  the  file  contain- 
ing the  CDL,  classifying  the  tokens,  and  invoking  the  appropriate  keyword 
processing  routine.  Some  keyword  routines  read  other  tokens  required  for 
the  particular  structure.  For  example,  the  RUN  keyword  requires  that  a 
token  representing  a sub-executive  be  read. 

When  scanning  and  processing  the  CDL,  it  is  necessary  to  save  models 
and  sub-executives  referenced.  This  is  required  when  it  is  necessary  to 
generate  BEGIN/REVERT  procedures  to  attach  the  files  for  each  model,  or 
when  it  is  required  to  generate  segment  loader  directives  for  the  sub- 
executives. 

As  sub-executives  are  encountered  in  the  CDL  on  RUN,  START,  IF,  etc. 
statements,  the  PMDL.REF  attribute  of  the  PARAM  entity  for  the  sub-executive 
contains  the  associated  model.  If  the  model  already  exists  in  the  list 
(MDL. CDL. LIST) , then  no  action  is  required.  However,  if  it  does  not  exist, 
the  sub-executive  list  is  searched  for  the  associated  model.  When  found,  the 
MODEL  entity  (stored  in  PMDL.PTR)  can  be  filed  in  the  MDL. CDL. LIST  set. 


A similar  procedure  is  followed  when  collecting  sub-executives  for 
the  segment  loader  directives.  If  the  sub-executive  already  exists  in  the 
list  (SBX.LIST),  no  action  is  required.  Otherwise,  it  is  filed  in  the 
SBX.LIST  set. 

When  macros  are  encountered  in  the  '"DL  text,  it  is  necessary  to  save 
the  current  card  image  being  processed  ..id  the  last  column  read.  This  is 
done  so  that  processing  of  this  card  image  can  resume  when  the  processing 
of  the  macro  is  complete.  Card  images  for  the  macro  are  represented  by 
CDL. STATEMENT  entities  in  the  MA. EXPANSION  set  for  the  macro.  Processing 
for  the  macro  terminates  when  the  last  entity  in  the  MA. EXPANSION  set  is 
processed.  When  the  processor  encounters  a macro  while  processing  a macro, 
the  current  macro  is  preempted  and  its  processing  state  (card  image  and 
last  column  read)  is  preserved  on  a stack.  The  data  structure  for  this 
stack  is  as  follows: 

EVERY  STACKED . MACRO  HAS 
A SM. CDL. STATE, 

A SM. MACRO, 

A SM. COLUMN, 

A SM. FIRST. CARD, 

AND  BELONGS  TO  THE  STACK. OF. MACROS 

where  SM. MACRO  is  the  MACRO  entity,  SM. ENTITY  is  a pointer  to  the  current 
CDL. STATEMENT  entity  being  processed,  SM. COLUMN  is  the  last  column  read, 

SM. FIRST. STATE  denotes  whether  this  is  the  first  card  image  of  the  macro 
or  not  (YES  or  NO),  and  STACK. OF. MACROS  is  the  stack.  When  processing  of 
the  new  macro  completes,  the  macro  previously  preempted  is  removed  from 
the  stack,  and  its  processing  resumes. 

Each  structure  of  the  CDL  defined  in  section  1.2  requires  that  certain 
information  be  stored  in  the  FLOW  vector.  This  information,  the  required 
data  structures,  and  stack  operations  for  each  keyword  are  described  below. 

3.1.1  RUN  Keyword 

When  the  RUN  keyword  is  encountered,  the  next  symbol  in  the  input 
text  is  assumed  to  be  a sub-executive.  Therefore,  the  table  of  sub- 
executives is  searched  for  the  sub-executive  name.  Legal  sub-executive 
types  for  the  RUN  command  are  computational  or  macro  expansions.  For 
macro  sub-executives,  nothing  is  stored  in  the  FLOW  vector  since  a substitu- 
tion must  be  made.  For  computational  sub-executives,  the  PARAM  temporary 
entity  of  the  sub -executive  is  stored  in  the  next  available  location  in 
the  FLOW  vector  (i, . This  is  illustrated  below. 
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3.1.2  IF  Keyword 

Since  IF  can  be  used  with  both  decision  modules  and  program  variables, 
the  token  following  the  IF  determines  what  will  be  stored  in  the  FLOW 
vector.  In  either  case,  three  positions  in  the  FLOW  vector  are  defined: 
the  pointer  to  the  appropriate  entity,  the  position  (negated)  in  the  flow 
vector  to  branch  to  if  the  condition  is  true,  and  the  position  (negated) 
in  the  FLOW  vector  to  branch  to  if  the  condition  is  false.  It  is  not 
possible  for  the  processor  to  determine  one  of  these  positions  until  the 
ELSE  for  the  IF  has  been  processed.  If  the  "true"  condition  is  assumed 
as  default  (i.e.,  the  clause  "IS  TRUE"  is  specified,  or  omitted),  then 
the  "true"  position  is  merely  the  current  counter  plus  2,  likewise,  if  the 
"false"  condition  is  specified,  the  "false"  position  is  the  same.  The  re- 
maining position  is  defined  when  the  "ELSE"  is  encountered. 

For  sub -executives,  the  following  illustrates  what  is  stored  in  the 
FLOW  vector. 


When  a variable  is  specified,  the  following  illustrates  the  linked 
structures  required. 


FLOW 

Vector 


PARAM 
* Entity 
PTYPE  - 
"$V.  IF$" 
PIVALUE  . 
Others 
not  used 


► Name  array 

Characters 

1-10 

Characters 

11-20 

Characters 

21-30 


V.  IF 
Entity 

"ttnamei  ■; 

V7NAME2  , 
V. OPERATOR 

Name  array 

Characters 

1-0 

Characters 

11-20 

Characters 


The  V. IF  entity  is  created  for  storage  of  information  about  the 
variables  specified  in  the  IF.  It  is  defined  as  follows: 

EVERY  V.IF  HAS 
A V.NAMEl, 

A V.NAME2, 

A V. OPERATOR 

A new  data  structure  must  be  created  and  placed  on  the  structure 
stack  so  that  the  correct  paths  can  be  defined  when  the  "ELSE"  and  "ENDIF" 
are  encountered.  This  data  structure  is: 

EVERY  CDL.IF  HAS 
AN  ELSE. PATH, 

AN  ENDIF. PATH, 

AN  IF.LINE.N0, 

A FND.ELSE 

Where  ELSE. PATH  is  the  position  in  the  FLOW  vector  containing  the  "false" 
path.  ENDIF. PATH  will  contain  the  position  in  the  FLOW  vector  following 
the  positions  up  to  the  "ELSE"  where  a branch  to  the  ENDIF  must  be  defined 
when  ENDIF  is  encountered.  IF. LINE. NO  is  merely  the  CDL  line  number  and 
FND.ELSE  is  used  to  denote  when  an  ELSE  was  encountered  for  error  detection 
of  multiple  "ELSE"  keywords  for  the  same  IF. 
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3.1.3  ELSE  Keyword 


The  current  position  In  the  FLOW  vector  must  be  defined  as  a branch 
to  the  ENDIF,  but  since  this  won't  be  available  until  the  ENDIF  is  en- 
countered, this  position  must  be  stored  in  the  ENDIF. PATH  attribute  of  the 
CDL.IF  entity  on  top  of  the  stack.  The  FND.ELSE  attribute  can  be  defined 
to  denote  that  an  ELSE  was  found,  and  the  FLOW  vector  position  stored  in 
ELSE. PATH  can  now  be  defined  as  a branch  to  the  current  FLOW  vector  position 
plus  one. 

Syntax  checks  must  also  be  made  when  the  ELSE  keyword  is  processed. 

The  use  of  a stack  simplifies  this  process.  Obviously,  when  an  "IF" 
structure  does  not  exist  on  the  top  of  the  stack,  a syntax  error  is  assumed. 
The  processor  does  not  attempt  to  look  ahead  to  determine  the  user's 
intention,  rather  it  looks  backward  on  the  stack  for  an  "IF"  structure. 

If  one  is  found,  it  is  associated  with  the  ELSE,  and  if  one  is  not  found, 
then  an  ELSE  without  a matching  IF  is  assumed. 

3.1.4  ENDIF  Keyword 

No  additional  positions  in  the  FLOW  vector  are  required  for  this 
keyword.  The  FLOW  vector  position  defined  in  ENDIF. PATH  on  the  stack  can 
now  be  defined  as  a branch  to  the  current  FLOW  vector  position.  This 
completes  the  processing  for  the  "IF"  structure,  the  stack  is  popped  and 
all  data  structures  destroyed. 

The  following  example  illustrates  what  is  stored  in  the  FLOW  vector 
for  an  "IF  THEN  ELSE"  structure. 

IF  A IS  TRUE 
RUN  B 

ELSE 

RUN  C 

ENDIF 

The  following  FLOW  vector  results: 

FL0W(1)  = PARAM  entity  of  sub-executive  A 
FL0W(2)  * -4  (true  path  negated) 

FL0W(3)  = -6  (false  path  negated) 

FL0W(4)  ■ PARAM  entity  of  sub-executive  B 
FL0W(5)  - -7  (branch  to  ENDIF) 

FL0W(6)  * PARAM  entity  of  sub-executive  C 


An  examination  of  the  stack  is  done  to  determine  if  a syntax  error 
has  occurred.  If  the  top  of  the  stack  is  not  an  "IF",  then  the  stack  is 
scanned  until  an  "IF"  is  found  or  the  stack  is  exhausted.  The  existence 
of  an  "IF"  requires  its  removal  from  the  stack.  When  no  "IF"  is  found, 
the  ENDIF  is  assumed  to  be  extraneous. 

3.1.5  DO  FOR  Keyword 

This  keyword  also  requires  a linked  list  to  be  set  up  in  the  FLOW 
vector  to  properly  store  the  data  needed.  Two  positions  in  the  FLOW 
vector  are  defined.  The  first  position  is  set  to  a PARAM  entity  defining 
the  structure  type  and  a pointer  to  another  entity  holding  information 
about  the  "DO"  structure.  This  entity  is  defined  as: 

EVERY  CDL.FOR  HAS 
AN  IN. NAME, 

AN  A. NAME, 

A B.NAME, 

A MQN.VARBL 

Where  IN. NAME  is  the  name  of  the  loop  index,  A. NAME  is  the  initial  value 
of  the  loop  and  B.NAME  is  the  last  value  of  the  loop.  MON.VARBL  is  the 
name  of  the  monitored  routine  if  one  exists. 

] 

The  second  position  in  the  FLOW  vector  is  the  FLOW  vector  position 
to  branch  to  when  the  loop  terminates.  The  following  illustrates  what  is 
stored  in  the  FLOW  vector. 


A new  type  data  structure  must  be  created  and  placed  on  the  structure 
stack  so  that  the  correct  path  can  be  defined  when  the  "ENDDO"  is  encountered. 
This  data  structure  is: 
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EVERY  CDL.DO  HAS 
A DO. LABEL, 

AN  ENDDO.PATH, 

A DO.LINE.NO, 

A DO. TYPE 

Where  DO. LABEL  contains  the  FLOW  vector  position  of  the  "DO"  origin, 
ENDDO.PATH  contains  the  position  in  the  FLOW  vector  which  will  be  defined 
as  a branch  to  the  end  of  the  DO,  DO.LINE.NO  is  the  CDL  line  number, 

DO. TYPE  is  the  type  of  the  DO,  "FOR"  or  "WHILE". 

3.1.6  DO  WHILE  Keyword 

This  keyword  is  treated  the  same  way  as  an  "IF"  keyword  since  what 
follows  "DO  WHILE"  is  identical.  The  only  difference  is  in  the  stack  pro- 
cessing where  a CDL.DO  entity  is  stored  in  STR. ENTITY  rather  than  a CDL. IF 
entity.  The  three  positions  in  the  FLOW  vector  are  defined  as  in  an  "IF" 
with  the  exception  of  the  "false"  path  position  defined  as  a branch  to  the 
end  of  the  "DO". 

3.1.7  ENDDO  Keyword 

This  keyword  defines  the  next  available  position  in  the  FLOW  vector 
to  a PARAM  entity  with  the  PTYPE  attribute  set  to  "$ENDD0$"  for  the  "DO  FOR" 
structure.  For  ENDDO' s associated  with  "DO  WHILE"  structures,  the  FLOW 
vector  position  contains  a branch  to  the  beginning  of  the  DO.  This  is 
necessary  since  some  high  level  languages  do  not  have  a true  "DO  WHILE" 
feature  and  the  generated  code  for  the  ENDDO  is  generally  a branch  -to  the 
beginning  of  the  DO.  The  following  illustrates  the  PARAM  entity  for  the 
"DO  FOR". 


FLOW  PARAM 


No  other  information  needs  to  be  stored  with  the  structure.  Even  if  a 
label  is  required  to  terminate  the  loop  (as  in  FORTRAN),  the  FLOW  vector 
index,  i,  would  be  used. 

The  FLOW  vector  position  defined  in  the  ENDDO. PATH  attribute  of  the 
CDL.DO  entity  stored  on  the  top  of  the  stack  can  now  be  defined  as  a branch 
to  the  current  FLOW  vector  position  (the  end  of  the  DO).  For  the  "DO  FOR" 
keyword,  it  is  the  second  word  reserved  when  the  "DO"  keyword  was  encountered. 
For  the  "DO  WHILE"  keyword,  the  false  path  position  is  defined  as  a branch 
to  the  FLOW  vector  position  of  the  end  of  the  DO  plus  1 (so  that  a branch  to 
the  outside  range  of  the  DO  is  effected). 

The  following  example  shows  the  FLOW  vector  positions  defined  with 
the  "DO  FOR"  keyword. 

DO  FOR  I * 1 TO  10 
RUN  A 
RUN  B 

ENDDO 
RUN  C 

This  would  produce  the  following  FLOW  vector. 

FL0W(1)  = PARAM  entity  holding  CDL.FOR  entity 
FLOW  (2)  =■  -5 

FL0W(3)  ■ PARAM  entity  for  sub-executive  A 
FL0W(4)  * PARAM  entity  for  sub-executive  B 
FLOW(5)  - PARAM  entity  for  the  ENDDO 
FL0W(6)  * PARAM  entity  for  sub-executive  C 

The  following  example  shows  the  FLOW  vector  positions  defined  with 
the  "DO  WHILE"  keyword. 


DO  WHILE  Z IS  TRUE 
RUN  A 
RUN  B 

ENDDO 
RUN  C 

The  following  FLOW  vector  would  result. 

FLOW(l)  * PARAM  entity  for  sub-executive  Z 
FLOW(2)  * -4  (true  path) 

FL0W(3)  **  -7  (false  path) 

FLOW(4)  * PARAM  entity  for  sub-executive  A 
FL0W(5)  ■ PARAM  entity  for  sub-exeuctive  B 
FLOW(6)  » -1  (branch  to  DO  origin) 

FLOW(7)  ■ PARAM  entity  for  sub-executive  C 
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When  the  "IS  FALSE"  clause  is  used,  the  values  of  the  true  and  false  paths 
are  switched. 


The  required  stack  operation  for  the  ENDDO  is  to  remove  the  first 
structure  from  the  stack  (pop  the  stack).  If  the  first  structure  is  not 
a DO,  a syntax  error  results,  and  an  attempt  is  made  to  locate  a DO  on  the 
stack.  If  one  is  found,  the  DO  is  removed  from  the  stack.  If  a DO  is  not 
found,  the  ENDDO  is  assumed  to  be  extraneous. 

3.1.8  START  Keyword 

This  keyword  is  essentially  the  same  as  the  RUN  keyword  with  the 
exception  that  only  phase  type  sub-executives  are  allowed.  The  PARAM 
entity,  when  retrieved  from  the  table  of  sub-executives,  is  stored  in  the 
next  available  position  in  the  FLOW  vector. 

3.1.9  GO  TO  Keyword 

Additional  data  structures  are  required  for  labels  so  that  all  label 
references  can  be  satisfied  when  the  entire  CDL  is  processed.  These  data 
structures  are: 

EVERY  CDL. LABEL  HAS 
A NAME. OF. LABEL, 

AN  ORIGIN, 

AND  OWNS  A REF. LIST, 

AND  BELONGS  TO  A SET. OF. LABELS 

EVERY  REFERENCE  HAS 
A REF. INDEX, 

AND  BELONGS  TO  A REF. LIST 

The  current  position  in  the  FLOW  vector  is  defined  as  a branch  to  the 
origin  of  the  label.  This  may  not  be  possible  if  the  origin  is  not  known. 
If  the  label  does  not  exist  in  the  SET. OF. LABELS,  then  a CDL. LABEL  entity 
is  created  and  filed  in  the  SET. OF. LABELS  set.  If  the  origin  of  the  label 
is  unknown,  then  a REFERENCE  entity  is  created  and  filed  in  the  REF. LIST 
set  with  REF. INDEX  set  to  the  current  FLOW  vector  position.  If  the  origin 
is  known,  then  the  FLOW  vector  can  be  defined  as  a branch  to  the  origin  of 
the  label. 

3.1.10  LABEL  Keyword 

When  labels  are  encountered  in  the  input  text,  a CDL. LABEL  is  created 
if  one  does  not  exist.  If  one  does  exist,  then  it  is  retrieved  from  the 
SET. OF. LABELS  set.  If  the  ORIGIN  is  non-zero,  then  this  is  a multiply- 


defined  label,  producing  a syntax  error.  If  the  ORIGIN  Is  zero,  then  the 
ORIGIN  Is  defined  as  the  current  FLOW  vector  position,  and  all  REFERENCE 
entities  in  the  label's  REF. LIST  set  can  be  satisfied. 

When  the  CDL  processing  is  completed,  the  ORIGIN  attribute  Indicates 
whether  a label  is  undefined  or  not. 


3.1.11  TEXT  Keyword 

The  TEXT  keyword  implies  that  card  images  up  to  the  ENDTEXT  keyword 
are  to  be  transferred,  without  modification,  to  the  generated  executive; 
or,  in  the  case  where  ampersand  appears  in  column  1,  individual  card  Images 
are  treated  as  text.  A PARAM  entity  representing  "no  operation"  is  created 
and  stored  in  the  FLOW  vector  first,  followed  by  a PARAM  entity  for  each 
card  image  in  the  text,  with  the  PIVALUE  attribute  defined  as  the  pointer 
to  the  card  image.  The  "no  operation"  entities  are  required  during  the 
translation  phase  to  insure  that  no  extraneous  code  is  inserted  in  the  text 
card  images.  The  contents  of  the  FLOW  vector  are  illustrated  below.  (Note 
that,  for  FORTRAN,  text  code  must  begin  in  column  7 or  beyond  and  not  exceed 
72.) 


3.1.12  END  Keyword 


A zero  Is  stored  In  the  next  available  location  in  the  FLOW  vector 
when  this  keyword  is  encountered. 

3.2  Translating  the  FLOW  Vector 

Translating  the  FLOW  vector  to  the  target  language  is  a relatively 
simple  process  since  there  are  only  two  data  types  stored  in  the  FLOW 
vector:  PARAM  entity  pointers,  and  negative  entities.  PARAM  entities 
can  be  one  of  seven  different  types. 

a.  Computational  sub-executives  (PTYPE  - "COMPUTES"  or  "PHASE") 

b.  Decision  sub-executives  (PTYPE  ■ "DECISION") 

c.  Variable  IF  (PTYPE  - "$V.IF$") 

d.  DO  FOR  (PTYPE  - "$CDL.DO$") 

e.  ENDDO  (PTYPE  - "$ENDDO$") 

f.  TEXT  (PTYPTE  - "TEXT") 

g.  No  operation  (PTYPE  - "NO. OP") 

In  addition  to  translating  the  FLOW  vector,  other  information  must  be 
written  so  that  the  resulting  main  program  and  executive  subroutine  will 
be  compiled  correctly  by  the  target  language  compiler.  The  translation 
steps  outlined  below  apply  when  the  target  language  is  CDC  FORTRAN  Extended 
(see  Reference  3). 

3.2.1  Writing  Out  the  PROGRAM  Card  and  Files 

Every  MODEL  entity  in  the  MDL.CDL.LIST  set  accumulated  while  scanning 
and  processing  the  CDL,  implicitly  requires  files  to  be  included  on  the 
PROGRAM  card.  These  files  and  their  sizes  can  be  retrieved  by  searching 
the  MDL.PLO.LIST  set  for  every  MODEL  entity  in  the  MDL.CDL.LIST  set.  To 
avoid  redundant  file  specifications  on  the  PROGRAM  card  (since  more  than 
one  model  can  reference  the  same  file  name),  PLO.FILE  entities  from  the 
MDL.PLO.LIST  set  are  filed  in  the  PGM.CRD.LIST  set  providing  one  does  not 
already  exist.  The  resulting  PGM.CRD.LIST  set  contains  unique  PLO.FILE 
entities,  where  the  names  of  the  files  and  their  buffer  sizes  can  be 
written  as  part  of  the  PROGRAM  card. 


3.2.2  Writing  Out  Calls  to  Frontend  Routines 

Frontend  routines  are  represented  by  SPGM  entities  filed  in  the  MDL.FE.- 
LIST  set.  For  global  frontend  routines,  "CALL"  statements  are  generated 
for  SPGM  entities  filed  in  the  MDL.FE.LIST  set  owned  by  the  global  MODEL 
entity.  "CALL"  statements  for  frontend  routines  for  each  model  are  generated 
by  scanning  the  MDL.FE.LIST  set  for  each  MODEL  entity  in  the  MDL.CDL.LIST 
set. 


If  more  than  one  model  references  the  same  frontend  routine,  then  only 
one  "CALL"  is  generated  for  that  routine.  This  also  holds  true  for  rearend 
routines. 


3.2.3  Writing  Out  the  Call  to  the  Executive 

This  is  a simple  procedure  of  just  writing  out  a "CALL"  to  the 
executive  controller  name  defined  on  the  CDL  initialization  file. 

3.2.4  Writing  Out  Calls  to  Rearend  Routines 

Rearend  routines  are  represented  by  SPGM  entities  filed  in  the  MDL.RE. 
LIST  set.  For  global  rearend  routines,  "CALL"  statements  are  generated  for 
SPGM  entities  filed  in  the  MDL.RE. LIST  set  owned  by  the  global  MODEL  entity 
for  rearend  routines.  "CALL"  statements  for  rearend  routines  for  each  model 
are  generated  by  scanning  the  MDL.RE. LIST  set  for  each  MODEL  entity  in  the 
MDL. CDL. LIST  set. 

3.2.5  Writing  Out  the  Main  Program  End 

This  involves  writing  out  STOP  and  END  to  the  output  file. 

3.2.6  Writing  Out  the  Executive  Subroutine  Header 

Given  the  executive  controller  name  defined  on  the  CDL  initialization 
file,  a SUBROUTINE  card  is  generated. 

3.2.7  Writing  Out  FORTRAN  Common  Blocks 

The  FORTRAN  common  blocks  defined  on  the  CDL  initialization  file  are 
not  stored  internally,  they  are  merely  copied  from  the  initialization  file 
to  the  output  file. 

3.2.8  Writing  Out  the  Executive  Controller  from  the  FIX)W  Vector 

The  FLOW  vector  contains  pseudo  GO  TO' s in  the  form  of  negative 
entries  referencing  FLOW  vector  array  entries.  In  translating  the  FLOW 
vector,  these  negative  entries  cause  the  generation  of  GO  TO  statements. 
Therefore,  it  is  necessary  to  perform  a pre-scan  of  the  FLOW  vector  and 
store  the  absolute  value  of  all  negative  entries  in  the  LIST. OF. LABELS  set. 
As  FORTRAN  statements  are  constructed  from  each  element  of  the  FLOW  vector, 
statement  labels  are  assigned  accordingly  whenever  the  top  entry  in  the 
LIST. OF. LABELS  set  matches  the  current  element  in  the  FLOW  vector. 

When  scanning  the  FLOW  vector  and  constructing  code,  it  is  first 
necessary  to  classify  the  FLOW  vector  entry.  When  the  FLOW  vector  entry 
is  negative,  it  is  a simple  matter  of  constructing  a GO  TO  with  the  label 
being  the  absolute  value  of  the  entry.  All  other  entries  in  the  FLOW 
vector  are  assumed  to  be  PARAM  entities. 

If  the  overlay  load  option  has  been  selected,  a "CALL"  to  any  sub- 
executive is  replaced  by  a "CALL"  to  this  sub -executive' s overlay.  A "MAIN" 
program  is  generated  for  each  overlay  (corresponding  to  a sub-executive) 
containing  a "CALL"  to  the  sub-executive. 
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If  the  PTYPE  attribute  of  the  PARAM  entity  is  "$7.1?$'',  then  the 
PARAM  entity  forms  the  linked  list  described  in  section  3.1.2.  The 
PIVALUE  contains  the  V.IF  entity  which  holds  essential  information  for 
translation.  The  next  two  positions  in  the  FLOW  vector  contain  the  true 
and  false  paths  respectively.  A description  of  the  actual  translation  is 
best  illustrated  by  an  example. 

Assume  the  following  CDL: 

IF  X < Y 
RUN  A 

ELSE 

RUN  B 

ENDIF 

END 

The  FLOW  vector  is  as  follows: 

FLOW(l)  = PARAM  entity  pointing  to  the  V.IF  entity 

FLOW (2)  = -4 

FLOW (3)  - -6 

FL0W(4)  - PARAM  entity  of  sub-executive  A 

FLOW (5)  - -7 

FL0W(6)  = PARAM  entity  of  sub-executive  B 


FL0W(7)  * 0 

The  following  code  would  be  produced  (LOAD  ■ N0RM): 

IF  (.NOT. (X.LT.Y))  GO  TO  6 

4 CALL  A 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 

GO  TO  7 

6 CALL  B 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 

7 RETURN 

END 

Notice  that  error  detection  code  is  generated  after  each  call  to  a 
sub-executive  assuming  that  the  number  of  the  error  is  stored  in  ERRNO, 
and  the  error  type  (fatal  or  non-fatal)  is  stored  in  ERRTYP. 

For  PTYPE  equal  to  "$CDL.DO$",  the  linked  list  described  in  section 
3.1.5  is  assumed.  The  CDL. FOR  entity,  containing  the  essential  information 
for  constituting  the  loop,  is  stored  in  the  PIVALUE  attribute. 


An  example  of  using  the  DO  FOR  is  as  follows: 


DO  FOR  I - 1 to  10 


RUN  A 
RUN  B 

ENDDO 

END 

The  FLOW  vector  is  as  follows: 

FLOW(l)  ■ PARAM  entity  pointing  to  the  CDL.FOR  entity 
FLOW(2)  - -5 

FL0W(3)  ■ PARAM  entity  of  sub-executive  A 
FLOW(4)  * PARAM  entity  of  sub-executive  B 
FL0W(5)  - PARAM  entity  for  the  ENDDO 
FL0W(6)  - 0 


Attributes  of  the  CDL.FOR  entity  would  be  defined  as  follows: 

IN. NAME  = "I" 

A.  NAME  - "1" 

B. NAME  - "10" 

MDN.VARBL  - blank 

The  following  code  would  be  generated  (LOAD  ■ N0RM) : 

DO  5 I = 1,10 

CALL  A 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 

CALL  B 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 

5 CONTINUE 

RETURN 

END 

If  a monitored  routine  were  associated  with  the  loop  index,  then  a 
call  to  the  routine  would  be  generated  after  the  DO  statement  and  error 
detection  code  would  follow. 

When  the  PTYPE  attribute  of  the  PARAM  entity  obtained  from  the  FLOW 
vector  is  equal  to  "$ENDD0$",  the  generated  code  depends  upon  the  type  of 
DO.  In  the  above  example,  the  generated  code  is  merely  a "CONTINUE"  with 
the  "DO"  label  to  mark  the  end  of  the  DO.  For  "WHILE"  type  loops,  a 
branch  to  the  beginning  of  the  loop  is  generated. 

If  the  PTYPE  attribute  is  equal  to  "DECISION",  then  the  PARAM  entity 
represents  a decision  type  sub-executive.  It  is  assumed  that  decision  sub- 
executives define  a global  variable  (LRESLT)  denoting  whether  it  is  true 
(LRESLT  • 1)  or  false  (LRESLT  - 0).  The  generated  code  is  essentially  a 
CALL  to  the  sub -executive,  error  code,  and  a branch  to  the  true  or  false 
path  (determined  from  the  two  FLOW  vector  positions  following  the  PARAM 
entity). 
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For  example: 


IF  A IS  TRUE 
RUN  B 

ELSE 

RUN  C 

ENDIF 

END 

would  translate  to  (LOAD  * OVL): 

CALL  OVERLAY (6HA  , IB,  0,  6HRECALL) 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 
L = LRESLT  + 1 
LRESLT  = 0 
GO  TO  (6,4),L 

4 CALL  OVERLAY (6HB  , 2B,  0,  6HRECALL) 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 
GO  TO  7 

6 CALL  OVERLAY (6HC  , 3B,  0,  6HRECALL) 

IF  (ERRNO.NE.O. AND. ERRTYP.EQ. FATAL)  RETURN 

7 RETURN 
END 

When  a FLOW  vector  entry  value  of  0 is  encountered  the  "RETURN"  and 
"END"  statements  are  generated  and  the  translation  process  is  complete. 

Card  images  specified  in  the  CDL  as  "text"  are  represented  by  PARAM 
entities  with  the  PTYPE  attribute  set  to  "TEXT".  The  card  image,  the  pointer 
of  which  is  stored  in  PIVALUE,  is  written  verbatim  to  the  translated  output 
file. 

Text  card  images  are  always  preceded  by  a "no  operation"  PARAM  entity 
in  the  FLOW  vector.  If  this  entity  did  not  exist,  it  is  possible  for  a 
label  to  be  assigned  to  a card  image  in  the  text,  thus  violating  the  defi- 
nition of  text  cards.  "No  operation"  PARAM  entities  in  the  FLOW  vector  are 
represented  by  PTYPE  set  to  "NO. OP".  They  are  translated  to  a "CONTINUE" 
statement  with  a label  equal  to  the  current  position  in  the  FLOW  vector. 

For  example 

TEXT 

CALL  A 
CALL  B 
X = X + 1 
ENDTEXT 
END 

would  translate  to: 

1 CONTINUE 
CALL  A 
CALL  B 
X - X + 1 
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Section  4.  Overlay  Load  Generation 

The  most  common  way  of  executing  a large  program  system  on  the  CDC 
6700  is  by  using  the  overlay  load  facilities.  The  program  system  required 
by  the  CDL  Processor  is  composed  of  a main  program,  an  executive  controller, 
and  the  sub-executives,  such  that  an  overlay  structure  is  naturally  formed. 
The  CDL  Processor  automatically  performs  all  the  steps  necessary  in  causing 
an  overlay  load. 

Currently,  the  overlay  load  option  is  available  only  for  FORTRAN 
EXTENDED  programs.  Basically,  the  main  program  and  executive  controller 
are  part  of  the  main  overlay  and  each  sub-executive  is  a primary  overlay 
(see  reference  2).  There  is  a slight  variation  in  the  code  generated  for 
the  executive  controller  causing  the  overlay  to  be  referenced  rather  than 
the  sub-executive  directly.  There  are  also  some  slight  changes  to  the 
generated  BEGIN/REVERT  Procedures  (see  section  6). 
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Section  5.  Generation  of  Segment  Directives 


CDC  segment  directives  (see  reference  2)  can  be  requested  when  the  core 
requirements  of  the  configuration  to  be  executed  become  very  large.  The 
segment  directives  generated  are  the  minimum  required  for  the  segment  loader 
(for  the  CDC  6700  SCOPE  3.4  system). 

The  CDL  processor  views  the  entire  system  as  two  levels:  the  root 
segment  (Level  0),  and  sub-executives  (Level  1).  The  root  segment  would 
contain  the  main  program,  and  executive  controller,  and  the  next  level  (1) 
would  contain  the  sub-executives.  All  other  modules  are  considered  movable, 
i.e.,  the  loader  assigns  each  module  to  a segment  that  can  be  accessed  by 
all  the  segments  referencing  the  module. 

This  option  is  specified  via  the  "PARM1  parameter  when  executing  the 
CDL  processor. 

When  the  CDL  has  been  processed,  the  SBX.L1ST  set  contains  PARAM 
entities  representing  the  sub-executives  specified  in  the  CDL.  Segment 
directives  are  generated  from  this  information. 

As  an  example,  assume  that  the  following  CDL  is  specified: 

START  A 

RUN  B 
RUN  C 
RUN  D 
RUN  E 

END 

and  assume  that  the  name  of  the  main  program  given  in  the  CDL  initialization 
file  is  MAIN.  The  following  segment  loader  directives  are  generated: 

ROOT  TREE  MAIN 
LEVEL 
TREE  A 
TREE  B 
TREE  C 
TREE  D 
TREE  E 

MAIN  GLOBAL  common  list 
END 

The  GLOBAL  common  list  must  be  predefined  on  the  CDL  initialization 
file  with  all  common  blocks  from  allnmodels. 


34 


Sectior.  6.  BEGIN/REVERT  Procedures 


An  optional  feature  of  the  CDL  processor  is  to  generate  CDC-compatible 
BEGIN/REVERT  procedures  that  execute  the  input  preprocessor,  attach  model 
related  files,  and  generate  the  load  sequence  to  execute  the  model(s) 
specified  in  the  CDL.  The  generated  procedures  operate  within  fixed  BEGIN/ 
REVERT  procedures  that  perform  functions  which  are  invariant  to  the  models 
requested. 

The  first  fixed  BEGIN/REVERT  procedure  (EXECUTE)  attaches  the  CDL 
processor,  the  master  old  program  library  and  performs  an  UPDATE  to  retrieve 
tne  initialization  file  for  the  CDL  processor.  A recursive  procedure  is 
invoked  (CDLPREPARE)  that  performs  functions  required  on  a case  by  case 
basis.  This  procedure  executes  the  CDL  processor  and  then  invokes  3 pro- 
cedures generated  by  the  CDL  processor. 

The  generated  procedure  that  is  invoked  first  (IPIPREPARE)  retrieves 
the  input  preprocessor  initialization  data  (IPI)  for  each  model  specified 
in  the  CDL.  The  CDL  processor  assumes  that  each  model  has  an  IPI  deck. 

The  generated  JCL  consists  of  an  attach  for  each  models'  IPI  file  and  then 
a sequence  to  combine  all  IPI  decks  onto  one  file.  The  MDL. CDL. LIST  set 
contains  MODEL  entities  of  those  models  referenced  in  the  CDL. 

The  second  generated  procedure  (FILES)  attaches  all  data  files, 
libraries,  and  default  block  data  files  required  for  loading  and  execution. 
The  names  of  data  files  to  attach  are  obtained  from  the  EXT. FILE  entities 
which  are  filed  in  the  MDL. EXT. LIST  set  for  each  model.  If  the  same  local 
file  name  is  specified  for  more  than  one  model  specified  in  the  CDL,  then 
the  first  models’  file  is  used.  Libraries  are  obtained  from  the  LIB. FILE 
entities  filed  in  the  MDL. LIB. LIST  set  for  each  model.  Default  block  data 
routines  are  obtained  from  the  BLK.FILE  entities  filed  in  the  MDL. BLK. LIST' 
set  for  each  model. 

The  third  procedure  (LDEXEC)  executes  the  input  preprocessor,  compiles 
the  main  program,  executive  controller,  and  override  block  data  routines, 
and  performs  the  load  sequence  required  for  execution.  The  load  sequence 
includes  a SEGLGAD  if  segment  loader  directives  were  generated,  a load  of 
the  main  program,  executive  controller,  default  block  data  routines,  and 
override  block  data  routines.  When  an  overlay  load  is  requested,  the  main 
program  and  executive  controller  are  part  of  the  main  overlay  while  each 
sub-executive  is  a primary  overlay. 

An  outline  of  typical  BEGIN/REVERT  procedures  is  given  in  Appendix  B. 
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APPENDIX  A 

The  information  on  the  initialization  file  is  needed  to  initialize 
the  CDL  processor. 


The  structure  of  this  file  is  as  follows: 

SUB-EXECS 

GENERIC  NAME  1 ROUTINE  NAME  1 TYPE  MODEL 

GENERIC  NAME  2 ROUTINE  NAME  2 TYPE  MODEL 


• 

MACROS 

SUB-EXECUTIVE 
(CDL  FOR 

END 

SUB-EXECUTIVE 
(CDL  FOR 

END 


MACRO  NAME  1 
THIS  MACRO) 

MACRO  NAME  2 
THIS  MACRO) 


1 


MONITORED  VARIABLES 

NAME  1 MONITORED  ROUTINE  1 

NAME  2 MONITORED  ROUTINE  2 


MODELFILES 


MODEL  NAME  1 

OPTIONAL 

DESCRIPTION 

LIBRARIES 

PFN  1 

LFN  1 

USERID  1 

CYCLE 

1 

PFN  2 

LFN  2 

USERID  2 

CYCLE 

2 

• 

• 

• 

• 

END 

BLOCK. DATA 

PFN  1 

USERID 

1 

CYCLE 

1 

PFN  2 

• 

USERID 

• 

2 

CYCLE 

• 

2 

END 

• 

• 

• 

• 

• 

• 

LOCAL 

LFN  1 

BUFFER 

SIZE  1 

EQUIVALENT  FILE  1 

LFN  2 

BUFFER 

SIZE  2 

EQUIVALENT  FILE  2 

• 

• 

• 

• 

• 

• w 

• 

• 

• 

END 


I 


A-l 


DATA 

PEN  1 

LEN  1 

USERID  1 

CYCLE  1 

PEN  2 

LEN  2 

USERID  2 

CYCLE  2 

• 

• 

• 

• 

• 

• 

• 

• 

END 

• 

• 

• 

• 

IPI 

PEN  1 

USERID  1 

CYCLE  1 

END 

DEF 

PEN  1 

USERID  I 

CYCLE  1 

END 

MODEL  NAME 

2 OPTIONAL 

DESCRIPTION 

END 

GLOBAL 


END 


• 

END 

FRONTHND  ROUTINES 
GLOBAL 

ROUTINE  1 
ROUTINE  2 


END 

MODEL  NAME  I 

ROUTINE  1 
ROUTINE  2 


END 

MODEL  NAME  2 


REAREND  ROUTINES 
GLOBAL 


ROUTINE  1 
ROUTINE  2 


END 

MODEL  NAME  1 

ROUTINE  I 
ROUTINE  2 


END 

MODEL  NAME  2 


OPERATORS 

OPERATOR  1 
OPERATOR  2 


target  language  equivalent 
target  language  equivalent 


LANGUAGE 

FTN  OR  .SIMII5 
PROGRAM  NAME 
NAME 

CONTROLLER  NAME 
NAME 


RECOVERY 

NAME 

COLONS 


COttfON  /NAME/ 


EXEC  COMKJNS 

COMMON  /NAME/ 


LOADER 

LOADER  DIRECTIVES 

SEGMENT 

GLOBAL  LIST  OF  COMMONS 

END 


SAMPLE  COL  INITIALIZATION  FILE 


SOB-EXECS 

GLOBAL 

AMSS 

AWSS.INIT 

TIME. UPDATE 

MASTER. TIMES 

PRE-LAUNCH 

POST-LAUNCH 

PRINT-PLOT 

MSL.LAUNCH 

PRE-PPIV 

TRICS  .LINK 

NAVSHP 

t p Tr»i 

TRICS. PATROL 

TRICS. TRANSITION 

TRICS.  FIRING.  INTERVAL 

PATROL 

RANGE. CHE K 

BOOSTER. SHAPING 

D OG  LEG 

TF.  CORRECT 

NINO.DNSTY 

MIS*  ACHIEV 

PARESULTS 

L AUNCHPTS 

TRANSITION 

SELECTION 

TG TOFF  SETS 

PRVALIOITY 

TRANSINIT 

VO 

NAVLIST 

PPIVLOAO 

TRRESULTS 

PIRE.INTL 

FUZE 

W-MATRIX 

PRESET-1 

PRESET-2 

C KINVERSE1 

PREPRVLIST 

CKEANOB 

PREPREAOIN 

C KINVERSE2 

COMPUTEPCO 

CHECK. PCO 

SINS-S/C 


...... 

MACRO 

GLOBAL 

...... 

MACRO 

GLOBAL 

AWINIT 

COMPUTES 

GLOBAL 

TIMEJP 

COMPUTFS 

GLOBAL 

MTIMES 

COMPUTES 

GLOBAL 

...... 

MACFO 

GLOBAL 

------ 

MACRO 

GLOBAL 

PRTPLT 

COMPUTES 

GLOBAL 

MSLLAJ 

OECTSI ON 

GLOBAL 

PREPPY 

COMPUTES 

GLOBAL 

TRCLNK 

COMPUTES 

GLOBAL 

NSSCHD 

COMPUTFS 

NAVSHP 

MACRO 

TRICS 

MACRO 

TRICS 

...... 

MACRO 

TRICS 

...... 

MACRO 

TRICS 

PATRON 

PHASE 

TRICS 

RANGHK 

OECISI ON 

TRICS 

BSHAPE 

DECISION 

TRIES 

DOGLEG 

COMPUTES 

TRICS 

TFCORR 

COMPUTFS 

TRICS. 

HINOE 

COMPUTES 

TRICS 

NTSACH 

DECISION 

TRICS 

WTPRF 

COMPUTES 

TRICS 

LNCHPT 

OEC  IS I ON 

TRICS 

TRANSM 

PHASE 

TRICS 

SELECT 

OECISION 

TRICS 

TGTOFF 

DECISION 

TRICS 

PRVAL 

DECISION 

TRICS 

TRINIT 

COMPUTES 

TRICS 

VERT  DE 

COMPUTES 

TRICS 

NAVLST 

COMPUTFS 

TRICS 

PPIVLO 

COMPUTFS 

TRICS 

NTTRF 

COMPUTES 

TPICS 

FIRINM 

PHASF 

TRICS 

FUZER 

COMPUTES 

TRICS 

MCMTRX 

COMPUTES 

TPICS 

PIFPOR 

COMPUTES 

TRICS 

STREPS 

COMPUTES 

TRICS 

CKINLI 

COMPUTES 

TRICS 

PRVL3T 

COMPUTES 

TRICS 

CKELBR 

COMPUT ES 

TRICS 

RFADIN 

COMPUTES 

TRICS 

CKFNLI 

COMFUTES 

TRICS 

PREPCO 

COMPUTES 

TRICS 

C K PC  0 

COMPUTES 

TRICS 

SAND  SC 

COMPUTFS 

TRICS 

RECYCLE 

RECYCL 

DECISION 

TRICS 

TAD. PRESET 

WRTTAO 

COMPUTES 

TRICS 

FILEV  1-AUTO 

LV1FI 

COMPUTES 

TRICS 

WRITE. TEAP. FILE 

WTEAPF 

COMPUTES 

TRICS 

PPIV 

PPIV 

COMPUTES 

PPIV 

IMU 

IMU 

COMPUTES 

INU 

COMMAND. SLEW 

CSLEWI 

COMPUT  ES 

IMU 

CSOIHU 

MACRO 

CSOIMU 

CSOL.IPU 

CSOIHU 

COMPUTES 

CSOIHU 

CSDL. IMU. DUMMY 

CSDDUM 

COMPUTES 

CSOIMU 

CSOPPV 

...... 

MACRO 

CSOPPV 

C SOL. PPIV 

CSOPPV 

COMPUTES 

CSOPPV 

ENVIHU 

HACRO 

ENVIHU 

ENVIR.IMU 

ENVIHU 

COMPUTES 

ENVIHU 

BOOST 

BOOST 

COMPUTES 

BOOST 

ES 

ESEXEC 

COMPUTES 

ES 

RV. RELEASE 

RELEAS 

OFCISI ON 

ES 

MARV 

HARV 

COMPUTES 

MARV 

WINOS. TO. FT/SEC 

W KTOFS 

COMPUTES 

TRICS 

MACROS 

AMSS 

RUN  PRE-LA JNCH 
RUN  POST-LAUNCH 

ENO 

PRE-LAUNCH 

« • 

••  A WSS  PRE-LAUNCH  COL  FOR  IOC 

* • 

00  WHILE  TINE  <*  TENO 
RUN  NAVSHP 

IF  TIHE  = TSTRCP  ••  TSTRCP  * TIME  TO  START  TRICS  PATROL 
RUN  TRICS. LINK  " LAT/LONS  FROM  NAV 
RUN  TRICS. PATROL 
FNOIF 

IF  TIME  = TBSN  " IS  IT  BATTLE  STATIONS  MISSILE 
••  CHANGE  T3  TRA NS  IT  10 N/FIRI NG  INTFRVAL  OELTA-T 

A OTAHSS  = OTTFI 

START  TRANSITION  '•  T3  SET  FCMODE  = TRANSITION 
RUN  TRICS. LINK  »»  LAT/LONG,  TO D( D/H/N/ S) , PFSET  TIME  FROM  NAV 
IF  PRVALIOITY  IS  TRUE 
RUN  TRANSINIT 
IF  SELECTION  IS  TRUE 
ENDIF 
ENOIF 
ENOIF 

i » 

••  LOOP  THROUGH  ALL  MISSILES  FOR  THIS  TIME  STEP 

CO  FOR  NMSL  = 1 TO  NHSLS 

**  EXFCUTE  COMMAND  SLEW  WHEN  TIME  * TSPPV(NMSL).  ALSO 

••  CORRECT  GLOBAL  T INF  IF  OTAWSS  HAS  JUST  CHANGED  FROM 

*•  the  patrtl  value  to  the  r ransition/fir.  -int.  value 
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IF  TIME  <=  TSPPVt  KMSL) 

IF  TIME  > TSPPV (NMSL)-DT AWSS 
TIME  = TSPPVCNMSL) 

RUN  PRE-PPIV 
RUN  COMMAND. SLFW 
ENOIF 
ENOIF 

IF  TIME  > TSPPV(NHSL) 

IF  TIME  < TLO(NHSL) 

»*  P=» IV  STARTED  BJT  NOT  FINISHEO 
RJN  ORE-PPIV 
RUN  IMU 
PUN  PPIV 

IF  TIME  = TSTGrOCNMS.1  ••  TSTGTO  = TIME  FOR  TGT.  OFFSETS 
START  TRANSITION  ••  FOR  THIS  MISSILE 
RUN  T RICS (LINK  ••  LAT^LONG  FROM  PP IV 
IF  RANGE, CHEK  IS  T*JE 
IF  TS  TOFF SETS 
ENOIF 
ENOIF 

RUN  TRRESULTS  ••  TRICS  TRANSITION  RESULTS  FILF 
ENOIF 

••  IS  IT  FIRING  INTFRVAL  PPE-LOOPS? 

IF  TIME  = T ISO ( NMSL) 

START  FIRE.INTL  ••  FOR  THIS  MISSILE 
RUN  TRICS.LINK  " TO  PASS  PPE-LOOPS  DATA 
RUN  W-MATRI > 

RUN  PRESET- 1 
FNOIF 

FNCIF 

**  IS  IT  FIRIhG  INTERVAL  POST-LOOPS? 

IF  TIME  = TLOCNMSL) 

START  FIRE.INTL  ••  FOR  THIS  MISSILE 
RUN  TRICS.LINK  ••  TO  PASS  POST-LOOPS  OATA 
RJN  PREPRVLIST 
RUN  PRESET- f 
RJN  PREPRFAOIN 
RUN  FILEV1-/UTO 
RUN  WRITE. TEAP.-ILE 
END  IF 
FNOIF 
ENDOO 

» • 

••  UPDATE  GL03AL  TIME 

L TIME  = TIME  ♦ OTAWSS 

••  INSURE  NEW  TIME  E*ACT 

& TIME  = AI NT ( T IME/ OTA  WSS  ♦ .5)  * OTAWSS 

ENOCO 

ENO 


POST-LAUNCH 


••  AH SS  POST-LAUNCH  COL  FOR  IOC 

• • 

00  FOR  NMSL  ■ 1 TO  NHSLS 

l OTAWSS  * OTBOOST 

RUN  BOOST 

l OTAWSS  * OTES 

RUN  ES 

IF  RV. RELEASE 

00  FOR  NRf  * 1 TO  NWS 
t OTAWSS  a OTNARi t 

RUN  MART 

ENODO 

END  IF 

ENOOO 

END 

TRICS 

RUN  TRICS.  PATROL 

RUN  TRICS. TRANSITION 

RUN  TRICS.  FIRING.  INTERVAL 

END 

TRICS. PATROL 

• • 

••  BEGIN  PATROL  MODE 

• « 

START  PATROL 

. i 

••  LOOP  FOR  ALL  FOOTPRINTS 

i . 

" ITH  F.  P.  EQUIVALENT  TD  NTH  MISSILE 
00  FOR  ITHFP  « FRSTFP  TO  LASTFP 
IF  RANGE. CHFK  IS  TRJE 

IF  BOOSTER. SHAPING  IS  TRUE 
RUN  OOSLES 
RUN  TF. CORRECT 
IF  MIS.ACHIEV  IS  TRUE 
EKOIF 

ENDIF 

ENOIF 

RUN  PARESULTS  ••  TRICS  PATROL  RESULTS  FILE 

ENOOO 
••  END  PATROL 

END 

TRICS. TRANSITION 

t • 

••  BEGIN  TRANSITION 

• « 

START  TRANSITION 
. « 

IF  PRVALIOITY  IS  TRUE 

. * 

RUN  TRANSINIT 
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*•  RUN  VO 

IF  SELECTION  IS  TRUE 

••  RUN  NflVLIST 

• « 

••  LOOP  FOR  ALL  FOOTPRINTS 

• • 

00  FCR  ITHFP  = FRSTFP  TO  LASTFP 
" COMPUTE  WINO  AND  DENSITY 
RUN  MIND  .ON  STY 
»•  CONVERT  NINOS  TO  FT/SEC 
RUN  NINOS. TO. FT/SFC 
RUN  PPI / LOAD 
IF  RANGE. OH^K  IS  TRUE 

Ir  TGT  OFFSETS  IS  TRUE 
FN)  IF 

ENDIF 

RUN  TRRESULTS 

ENOOO 

EN  OIF 

ENOIF 

* « 

••  END  TRANSITION 

i « 

FND 

TRICS. FIRING. INTERNAL 

BEGIN  FIRING  INTERVAL 
START  FIRE.INTL 

• i 

**  LOOP  THROUGH  AIL  FOOTPRINTS 

« i 

DO  FOR  ITHFP  s FRSTFP  TO  LASTFP 
•*  PRE-LOOPS 

RUN  FUZE 
RUN  N-MATRIX 
•»  RUN  VO 
RUN  PRESET-i 
RUN  CKINVERSEi 

•POSTLOOP* 

RUN  SINS-S/C 
RUN  PRFP  IVLIST 
RUN  CKEANCB 
RUN  PPE SET -2 
RUN  PREFREAOIN 
RUN  CKINVE RSE2 
RUN  COMPUTEPCO 
RUN  CHECK. PCO 
IF  RECYCLE  IS  TRUE 
**  GO  TO  POSTLOOP 
ENOIF 


ENOOO 

" ENO  FIRING  INTERVAL 


* 


ENO 

HOOELFILES 

GLOBAL 


LIBRARY 

PGNLIBNASTER 

NASTERL 

NTH 

PGNLIBVOGHG2 

VOLIB 

NTH 

ENO 

LOCAL 

INPUT 

SYSIN 

6l» 

INPUT 

OUTPUT 

256 

ST  SOUT 

256 

OUTPUT 

DEBUG 

256 

OUTPUT 

/DUNIT 

LVLOUT 

256 

OUTPUT 

ENO 

OATA 

ENO 

IPI  OATfCONASfERTEMPU TE  NTH 

ENO 

OEF  0AT8CDHASTERDEFAU- TBATA  NTH 

ENO 

BLOCK. OATA 

DATRELNASTEROEFAU. TOATA  NTH 

ENO 


END 

NA YSHP 


LIBRARY 

OGMLIBNAVSHP 

NAVSHPL  NTH 

ENO 

LOCAL 

S YOUNT 

512 

V DUN IT 

NAYUNT 

512 

SHUNT 

512 

NSPLT 

512 

END 

OATA 

ENO 

IPI  DATBCDNAYSHPTE  MPLA  TE 

ENO 

OEF  0AT8C0N  A YSHPDEF AJ. TD  ATA 

ENO 

BLOCK*  OATA 

0 ATRELN AVSHPDEFAULTOA  TA 

ENO 

ENO 

PPIV 

LI3RARV  PGHLIBPPH  PPIYI 

ENO 

LOCAL 


NTH 

NTH 

NTH 

NTH 


512 
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ENO 


PPYPLT 
r E APJN 


OAT  A 
END 

IPI  B ATBCDPPIYTENPL AT  E NTH 

END 

DFF  3ATBC  OPPI VQEFA  ULTB  AT  A NTH 

END 

BLOCK. DATA 

3ATRELPPIVCEFAULTDATA  NTH 

r NO 

ENO 
I MU 


LIBRARY 

ENO 

LOCAL 

FNO 

OATA 

ENO 

PGMLIBIMU  IMUL 

NTH 

IPI 

B A TBC 01  MUTE PPL  ATE 

NTH 

FNO 

DEF 

DATBCOIHUCEFAULTJATA 

NTH 

END 

BLOCK. DATA 

OA TRELI MUCEF AULTD  ATA 

NTH 

ENO 


F NO 

CSDIMU 

LIBRARY  P3MLIBCSOIMU  CSPI1UI  NTH 

ENO 

LOCAL 

CSOPLT  512 

END 

OATA 

END 

IPI  0 A TEC DC SOI  MUTE HP. A TE  NJH 

F NO 

OFF  3ATECOCSDIMUO- FAULTQATA  NTH 

END 

BLOCK. DATA 

OATRELCSDIMUDEFAJlTDATA  NTH 

ENO 

ENO 

CSOPPV 

L IB  PA  FT  PGMLIBCSOPPV  CSOPsVL  NTH 

f;nd 

L OCA. 

PLFILE  512 

ENO 
DATA 
END 
IPI 
El 


OA  TBCOCSOPPVTEMP.ATE 


NTH 


OEF  d atbcdcsoppvdffau. toa  ta  nth 

END 

BLOCK. DATA 

3 ATRELCSOPPVOE  FAULTOATA  NTH 

ENO 

END 

ENVINU 

END 

BOOST 

LOCAL 

BSTPLT  512 

ENO 

END 

ES 

LOCAL 

ESPLT  512 

ENO 

END 

MARY 

LOCAL 

1RVPLT  512 

END 

ENO 

MONITORED  VARIABLES 

ITHFP  3NXTFP 

FRONTENO  ROUTINES 
GLOBAL 

MI  NIT 
MASLC1 
MASLC2 
MASLCT 

ENO 

NAVSHP 

AM INIT 

NAVBLO 

SHPBLD 

NS8LD 

VOCOH 

NSLC 

END 

TRICS 

INIT 

TRCLC1 

TRCLC2 

ENO 

PPIV 

AWINIT 

PPVLC 

ENO 
I MU 

AH INIT 


A-ll 


1 


IMULC 

ENO 

CSDIMU 

A W INIT 
ACCBD 

iNueo 

ELCOBO 

PLAT80 

iONBO 

GIHBBD 

CSOLC 

ENO 

CSOPPV 

AWINIT 

5SPLC 

ENO 

FNVIMU 

AWINIT 

ENVLC 

E NO 
BOOST 

AWINIT 

BSTLC 

ENO 

ES 

AWINIT 

ESLC 

FND 

MARV 

AWINIT 

NRVLC 


END 

FEAREND  ROUTINES 


GLOBAL 

FNO 

TRICS 

TREAR 

ENC 

RECOi/FFY 

SOS 

OPERATORS 

< 

.LT. 

< = 

.LE. 

> 

.GT. 

> = 

• GE« 

r 

.EG. 

A — 

.NE. 

LANGUAGE 

FTN 

PROGPAM  NAPE 
AWSS 
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CONTROLLER  NAME 
AWSSFX 
COMMONS 
C 

C / AO  3 2 2/  FILE  NAMES  - INTEGER,  CONSTANTS 


COMMON  /A00?2  / 

NAVUNT 

9 

SHJNT 

f 

SVDUNT 

1 

9 

NSPLT 

9 

PPVPLT 

» 

CSDPLT  , 

BSTPLT 

2 

9 

ESPLT 

9 

MRVPLT 

» 

TRCPLT 

3 

9 

PLFILE 

I MESER 

NAVUNT 

9 

SHJNT 

» 

SVDUNT 

1 

9 

NSPLT 

9 

PPVPLT 

> 

CSOPLT  , 

BSTPLT 

2 

9 

rSPLT 

9 

MRVPLT 

> 

TRCPLT 

3 

9 

PLFTLE 

C 

C /T 00  22/  I/O  FILE  NAMES  - INTEGER,  CONSTANTS 

COMMON/ TOO  22/ 


1 SYSIN 

» 

SY  SOUT 

» 

PUNCH 

» 

CATUNT 

» 

PRFUNT 

, TPFUNT 

2 , TPFUNT 

t 

VDUNIT 

i 

GUPCRT 

» 

P SOUNT 

» 

RTUNIT 

3 , PLOCRF 

, 

TEAPUN 

INTEGER 

SYSIN 

, 

SYSOUT 

, 

PUNCH 

» 

CATUNT 

, PRFJNT 

1 

, 

TRFUNT 

» 

T PFU  NT 

» 

VDUNIT 

> 

PSDUNT 

, RTUNIT 

2 

» 

GUPCRT 

3 

» 

PLOORF 

r 

TEAPUN 

C 

C /TO  531/  INTEGER  I/O  OPTION  VARIABLES 


COMMON/T05 31/  LV20UT  , OUTlVL  , LVLOUT  , LVLSUP 
1 , OETD  fP  , OMF3JT  , DMPSUP  , NACOUT 

INTEGER  OUTLtfL  , DETD1 P , OMPOUT  , DMPSUP 

EXEC 

C 

C / A W SO  0 1/  GLOBAL  TIMES,  COMPUTED,  SIMPLES 

COMMON  /AWS  001/  TIME  , TSPATR,  TB  SM  , TSTRCP,  T1SQMX,  T.3HX 
C 

C / AWS  Q 0 6/  GLOBAL  TIMES,  COMPUTEO,  ARRAYS  <#  MISSILES! 

COMMON  / AW  3 0 06/  TSPPV  (2%),  TSTGT0<24>,  TlSQ  (24),  TLO  (241 

1 , TO  (24),  DT 1SLO ( 24) 

C 

C / Aw  5 0 09/  GLOBAL  OELT  A -T  * S - REAL 

COMMON  / AW  SO  0 9/  OTAfcSS  , NAVOT  , OTPPIV  , DTIMU  , 0TB03S 

1 , DTFS  , DTMARV  , DTP ATR  , OTTFI 

PEAL  NAVDT 
C 
C 

C / A WS  0 10/  GLOBAL  COU>JTER(S) 

COMMON  / A WSO 10/  NMSLS 
C 
C 

C /AWS500/  GLOBAL  TIMES,  INPUT,  SIMPLES 

COMMON  / AWS5  00/  TSTART,  DTlS IT , DTLPAT,  OTSTPP,  TEND 
C 

C / TOO  3 3/  TARGET  PACKAGE  DATA  - INTEGER,  VARIABLES 
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COMMON/TOO  0 3/ 

1 OASFLG  , FP 10  , ICONF  , NFP 

2 NRV  , NSTOP  , TFOPT 


INTEGER  3 A SFLG  , FPIO  , TFOPT 

C 

C /T 00 1 8/  GLOBAL  CONTROL  FLACS 

COHHON/T  0018/ 

1 FRRNO  , rCMOOE  , ERRTVP  , LRFSLT 

2 , SUPRES  , TRUNIT 

INTEGER  ERRNO  , FCHOOE  , ERRTYP 

1 t SUPRES  , TRUNIT 
C 

C /T  00 19/  GLOBAL  CONSTANTS  - ALPHA,  VARIABLES 

COHHON/T 0019/ 


1 

BCKFIT 

i 

ESG 

, FAIL 

> 

FALSE 

» 

FATAL 

* 

FIRINT 

, 

2 

INVALO 

i 

MK  2 

, NFATAL 

9 

NGIVEN 

» 

NO 

9 

NULL 

9 

3 

PASS 

» 

PATROL 

9 TRANSI 

9 

TR10NT 

t 

TRUE 

1 

VALID 

9 

4 

YES 

> 

NORMAL 

, instnt 

5 

, BLANK 

t 

INPUT 

, OUTPUT 

9 

STNDRO 

t 

VACUM 

INTEGER 

BCKFIT 

, ESG 

9 

FAIL 

9 

FALSE 

t 

FATAL 

9 

1 

FIRINT 

, PASS 

9 

PATROL 

9 

TRANSI 

t 

TRIDNT 

9 

2 

TRUE 

, VALID 

9 

YES 

3 

9 

BLANK 

, OUTPUT 

9 

STNORO 

9 

VACUM 

C 

C /T  0027/  GLOBAL  - INTEGER,  VARIABLES 

C OMMON/ TO  027/ 

1 ITHFP  , NHSL 
C 

C /T0027K/  GLOBAL  - IMTEGFR,  VARIABLES 

CONMON  /T0  027K/  JTHFP 
C 

C /T0564K/  FOOTPRINT  CONTROLS  - INTEGEP,  INPUT. 


COMMON  /TO  564 K/  FRSTFP 

9 

LAS  T FP 

INTEGER  FRSTFP 

COMMON  /PPIV08/  TSC 

soe: 

9 

COEC 

* 

, S3F 

CBr 

* 

, TSO 

TO.  3 

9 

AIX 

, AIY 

* 

, AIZ 

A IXZ 

9 

AIYZ 

, A IXY 

♦ 

, AIXX 

AIYY 

9 

A TZZ 

, T 

C 

C 

LOAOER 

LOSET  ( FILES* GUPCRT) 

LOSET( US€P  = SYST  EMC) 

SEGHE  NT 

(ROOT  SEGMENT  GLOBAL  COMMONS  GO  HERE) 
ENC 
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fixed  begin/revert  procedures 


EXECUTE (*I* INPUT 
•NOL*,*QO*,*CY*5 
•LI»T*VES.*JCL=YI 
♦TA3LES«NO,*WARN: 
/* 

/*  FILES! 

/*  'BOTH  COLP 

/•  SIHU2  ■ 

/*  SI HU 3 

/• 

/•  SI HUB 

/•  SIHU6  i 

/• 

/*  'CDLP  * 

/*  SIHU31 

/*  SI HU 33 

✓ * SIHU35 

/*  SI HU 37 

/* 

/•  SIHU39  ■ 


,*L* OUTPUT, *10* NTH, *B*NTH,*NAP* SB ,*JCLFILE*.*EXEC* YES, 
»*RET*YES,*IFOEF*TRlCSK» 

ES,  *L0AD*N0RH»*LC*72» 
fN0.*LASTV*N0) 


AN  0 INPUT P* 

« 3UHHY  FILE  CREATEO  TO  SIGNAL  "LAST  CASE" 
' FILE  ON  WHICH  OVERRIDE  NUHERICAL  DATA  IS 
WRITTEN  BY  *COLP*  FOR  *INPUTP* 
i SYSTEH  INPUT  FILE 
SYSTEH  OUTPUT  FILE 


* COL # INITIALIZATION  FILE 

FILE  ON  WHICH  "CANNEO"  COL  *S  RESIOE 

FILE  OF  CDL  SPECIFICATIONS  REAO  BY  *CDLP* 

GENERATED  B/R  PROCS  I • IPIPREPARE  *.  'FILES*. 

AND  ' LOEXEC  * ) , 3 FILES 

FILE  ON  WHICH  SCRIPTED  FORTRAN  HAIN  PROGRAN 
A NO  EXECUTIVE  CONTROLLER  ARE  WRITTEN 


/*  SIHU41  * FILE  ON  WHICH  SEGHENT  LOAOER  DIRECTIVES  ARE 

✓ * 4R1TTEH 

/* 

/•  * INPUTP  * 

/»  SI  Hull  = INITIALIZATION  FILE 

/*  SIHU13  * DEFAULT  DATA  FILE 

/*  SIHU17  = DYNAHIC  DEFAULT  DATA  FILE 

/•  SIHU19  * SCRATCH  FILE  ON  WHICH  COHHON  BLOCKS  ARE  WRITTEN 

/•  SIHU21  * 3 LOCK  OATA  SUBROUTINE  FOR  SIHPLE  VARIABLES 

/*  SIHU23  * SLOCK  OATA  SUBROUTINE  FOR  TABLES 

✓ * 

IF  (INTERCOH .BATCH) 

OISCONT »*L« 

ENOZF (BATCH) 

/* 

/*  declare  file  buffer  sizes 
/• 

FILE (*I.BFS*200B) 

FILE! *L.BFS*200B ) 

FIL£(S1HU2.8FS*1103) 

FILE  (SIHU3.BFS* 2003) 

FILE  (SIHU31  »8FS=  2008) 

FILE  (SIHU33.SFS*  200  8) 

FI LE ( SI HU35 ,8FS= 200  B ) 

FILE  (SIHU37  ,BFS*  200  B) 
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FILE (SIMU39«BFS= 200 81 
FILE (SINUA1 «BFSS  200  B) 

FILE  (SIHU11 »8FS= 200B) 

FI LE ( SIMU13 ,BFS= 200  8) 

FILE ( SIHU17 »BFS= 200  B) 

FILE ISINU19  .8FS=  200 B) 

FILE  (SIHU21  »BFS=  200B) 

FILE  (SIMU23»BFS=  200  B) 

/* 

/•  RETURN  l ATTACH  *SVSTEH  LIBRARY* 

RETURN. SYSLIB. 

ATTACH.SYSLIB. 

/*  RETURN  FILES  USEO  BY  »CDLP*  AND  *INPUTP* 

RE  TURN,  SI  MU  2.  SIM  U3. 

/*  RETURN  AND  AITACK  *COLP*  FILES 
RETURN, SIMU35.SIHU3 7. SIHU39.SINU41. 

IF (-FILE.CQLP.USERQID) 

ATTACH. COLP.CDLP,  I0=NTH,MR»1. 

ENOIF (USEROIU) 

/*  RETURN  ANO  ATTACH  'INPUTP*  FILES 
RETURN, SIMU 17 .SI  HU1  9*  SIMU21.  SIHU23. 

RETURN. INPUTP. 

ATTACH, INPUTP.INPUTP.IO*NTH.MR*l. 

/ * CREATE  OR  ATTACH  *COLP*  INITIALIZATION  FILE 
IF (~FILE,SIMU31,  USERDID) 

COMMENT.  USER  OIO  NOT  ATTACH.  CREATE  COL  INIT  FILE 
RETURN.OLOPL. 

ATT  ACH. OLOPL.P6MO  PLM ASTER. 10s *10 • MR* 1. CY**CY • 

UPDATE. 0. 8. Q,  I=C0  LIMIT  »L=  0 » Cz  SIMU31 . 

RETURN.OLOPL. 

ENUIF (USEROIO) 

RETURN, COLI NIT. 

COMMENT • ****  NOTES  THE  CONDITIONAL  ATTACH  OF  SINU33 
COMMENT.  (“CANNED**  COL*S>  OELETEO  FROM  HERE. 

/* 

/•  BEGIN  RECURSIVE  PROC  FOR  COL  PREPARATION,  MODEL  EJCCUTION 

BEGIN, COLPREPARE, ♦TILE, 1**1. L**L. 8**0. NAP**NAP.JCL FILE** JCL FILE. EXEC**EXEC, 

LIST  = *LIST, JCL=*JC.  ,LOAO**LOAO.LC**LC, 

TABLESs#TABLES,HARN*  *NARN, L ASTV**LASTV • 

/* 

IF (INTERCOM .BATCH) 

IFC(EQ,*L  .OUTPUT.  NOUTPUT) 

ROUTE, *L.OC=  PR,  TIO=C,FIO**B. 

ENOIF (NOUTPUT) 

ENDIF (BATCH) 

/* 

/•  CLEAN  UP  FILES 
/*  *C0LP*  1 ‘INPUT?  * 

RETURN.SINU2.S1H U3.  COLP, INPUTP. 
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/*  'COLP*  (EXCEPT  EXEC.  I CONTROLLER  (SINUS))) 
RETURN#SIHU31#S1Hu3  5#sIHU37. 

IFC( EQ,*EXEC. YES #NJ EXEC) 

RE TURN, SI HUAI. 

ENOIF  ( NOEXEC) 

/•  ‘INPUT P*  INIi . FILE  ( DEFAULT  DATA  FILE 
RE TURN* SI HU 11, SI HU1  3. 

/*  ' INPUTP'  (EXCEPT  B.  O.  SINPLES  (SINU21)  & TABLES  (SIHU23)) 
RETURN #SI HU 17 , SI Hul  9. 

/*  USER'S  JCLFILE 
IFC( NE#*UCLFILE# .NULL) 

RETURN#*  JCLFIlE. 

ENOIF (NULL) 

REVERT. 

EXIT  #S. 

IFC(EQ#*L#OU{  PUT #RU  U TE) 

IF (INTERCOM# INTCOH) 

ROUTE#*L»DC=PR#  T IQ*C.F IO»*B. 

ENOIF (INT CON) 

ELSE (ROUTE) 

IF (BATCH#  NOTINT) 

ROUTE, *L.DC=PR#  TID-C. 

ENOIF (NOTINT) 

ENOIF (ROUTE) 

BEGIN, ABORT #*FILE,PROC*EXECUTE. 

RETURN# COLP. INPUTP. 

/*  RETURN  FILES  IF  REQUESTED 
IFC(EQ,*RET,YES,  NORET) 

RETURN# SI HU21#  SIHUZ3# SIHU39#  SIHU17 #SINU19#  SIHU37 • 

RETURN#  Si  HU 31# SIN U33#  SIHUZ # JIHU3# SIMU35.SIMU11, SIHU13* 
ENDIF(NORET) 

REVERT  # ABORT. 

/DATA  COLINIT 
•IOENT  IFOEF 
•DEFINE  *IF OEF 
•COMPILE  COLHASTER 
/EOR 


CDLPREPARE(*I*.*L=,  *8*, *MAP*,*JCLFILE*,*EXEC*, 

*L  1ST* ,*JCL* •♦LOAD*  »*LC«* 

•TABLES* **MARN*«  *LASTV*I 
/* 

/*  EXECUTE  THE  *COL  PROCESSOR* 

RE  TURN  *SIHU39*  SIHlfe  1 • l*COLP*) 

REMIND ,SIMU31,SIMU3 7. 

COLP* SINUS*  *I*SI MUo*  *L • PARM, LOAO* •LOAO.L IST**LIST • JCL**  JCL  »LC**LC. 
/* 

/*  JCL  FILE  LOGIC* 

/• 

/*  IF  *COLP»  JCL  REQUESTEO 

/*  IF  USER  OID  NOT  ATTACH  HIS  OMN  JCL  FILES 

/*  CREATE  FROM  *C0LP*  SCRIPTED  FILES 

/*  ELSE 

/•  USE  USER*S  ATTACHED  JCL  FILES 

7*  ENOIF 

/*  ELSE 

/•  IF  SI  K*.. E JCL  FILE  SUPPLIEO 

/*  CREATE  3 SEPARATE  JCL  FILES 

/•  ELSE 

/•  ASSUME  USER  HAS  ATTACHED  3 JCL  FILES 

✓ • ENOIF 

/•  ENOIF 

/• 

IFC(EQ**JCL  *YES* NOJCL) 

COMMENT.  *COLP  * SCRIPTED  JCL  MAS  REQUESTED* 

COMMENT.  COMBINE  3-FILE  PROCEOURE  FILE  ONTO  3 FILES 
COMMENT.  OR  USE  JSER*S  ATT ACHEO  COPY  OF  A GIVEN  PROC  FILE. 

COMMENT.  IPIPROC  - PROCEOURE  FILE  CONTAINING  *IPIPREPARE* 

COMMENT.  FILPROC  - “ ‘FILES* 

COMMENT.  LEXPROC  - “ *LOEXEC* 

IF  C-PF * IPIPROC  *N0 NE) 

REMIN0*SIMU37*I  PIPROC. 

COPYCR*  SIMU37*I  PIPROC. 

REMINO*  IPIPROC. 

ENOIF (NONE) 

IF (-PF (FILPROC  *N0NE) 

REMI NO*  SIMU3 7.F ILPROC. 

SKIPF*SIMU37  *2* 0*C. 

COPYCR*  SIMU37.F  I LPROC. 

REMINO*  FILPROC. 

EVOIF (NONE) 

IF  (-PF, LEXPROC  .NONE) 

REMINO*  SIMU37 »L EXPROC. 

SKIPF.SIMU37 ,4,  0,C. 

COPYCR. SI MU37.L EXPROC. 

REMINO* LEXPROC. 

ENDIF(NONE) 

ELSE (NOJCL) 

COMMENT.  NO  *COLP*  JCL  MAS  REQUESTED,  USE  USER*S  FILE(S) 


IFC ( N£  * *JC  LF1LE**  NULL > 

RENINO* JCLFILE. 

COPYCR,  JCLFILE,  IPIPROC. 

COPY CR.  JCLFILE,  FILPROC. 

COPYCR*  JCLFILE*  LEXPROC. 

E>l OIF  (NULL) 

ENOIFCNOJCU 

/• 

/*  BEGIN  'IPIPREPARE*  IF  USER  OIO  NOT  ATTACH  HIS  OHN 
✓ * * INPUTP*  INITIALIZATION  FILE 
iF(~FILE*SIHUll*  USER  OIO) 

CONNENT.  

BEGIN.IPI PREPARE.  IPIPROC. 

ENOIF (USEROIO) 

/*  BEGIN  PROC  TO  ATTACH  FILES*  LIBRARIES*  BLOCK  OATAS 

CONNENT.  

BEGIN, FILES, FILPROC. 

/* 

/*  BEGIN  PROC  TO  EXECUTE  *INPUTP*  (TO  PROCESS  OVERRIDE 
/•  NUMERICAL  DATA),  COMPILE  THE  FTN  COOE  GENERATED  BY  *COLPf* 

/*  AND  LOAD  ANO  EXECUTE  THE  PROGRAM  CONFIGURATION  REQUESTEO. 

CONNENT.  

begin,loexec,lexproc,i=*i.l=*l  *B=*8*NAP**MAP,EXEC»*EXEC* 
tables=*tables*n ar4=*narn,lastv=*lastv. 

/* 

/*  RECURSE  FOR  NEXT  CASE 

/•  (IF  FILE  SIHU2  4A«  CREATED*  LAST  CASE  HAS  BEEN  READ) 

IF (-FILE* SI HU2,S  TOP ) 

BEGIN* COL PREPARE*  *FILE»I=*I*L=*L*  B**B»NAP**MAP, JCLFILE** JCLFILE * 

LIST=*LIST. JCL=  *JCL  »L0 AO=#LO AD  * LC**LC  »EXEC  = *EXEC • 
TABLES=*T ABLES ,HARN=*H ARM, LAST V**LASTV. 

ENOIF (STOP) 

REVERT. 

EXIT.S. 

BEGIN*  ABORT  ,*FlLE,PROC=CDLPREPARE. 

REVERT, ABORT. 


GENERATE!)  8EGIN/RE  VERT  PROCEDURES 


XPIPREPARE. 

RETURN, IPI. 

RE  TURN, BCD. 

ATTACH, SCO, DATBC DMA  S TER TEMPLATE ,IO*NTH » 
COPT CR, BCD, IPI* 

RETURN, BCD* 

ATTACH, BCO, 0AT8C0TRICSKTEMPLATE,I0*NTH. 
COPTCRvBCD, IPI. 

RETURN, BCD* 

RENINO.IPI. 

COMBINE,  IPI , SI  HU  11,  2* 

RE MI NO, SI HU  11 • 

RETURN. IPI. 

REVERT* 

EXIT ,S* 

BEGIN, ABORT ,PROFIU  PROC*IPIPREPARE. 
REVERT (ABORT) 


FILES. 

RETURN*  SIMPLE  •TABLES. 

RET URN, HASTEN L 

ATTACH* HAST  ERL  .PGMLIBNASTER,  IO=NTH, NR«  1. 

RETURN*  TRICSL 

ATTACH, TRICSL  ,P GHLIBTRIC SK» IO»N TH,MR*1. 

RETURN. VOLIB 

ATTACH*  VOLIB  ,»G  MLIBVDGHG2,  I0»NTH,MR*1. 

RETURN, N0LB1. 

ATTACH*  HOLBl* OAT  REL  HASTEROEFAULTOATA*IO*NTH*MR«l. 
IF (-FILE.SINU13,  USEROIO) 

RETURN, OEF. 

ATT  ACH.QEF*  DATBCOMASTEROEF AULT  OAT  A * 10*  NTH*  MR*1. 
COPT CR* OEF*  SIMPLE. 

COPrCR.OEF* TABLES. 

ENOIF (USEROIO) 

RETURN, CATUNT 

ATTACH.CATUNT  ,5  ELECT  IONOAT  AK,  IO*NGS,  MR=1 . 

RETURN, MDLB2. 

ATTACH*H0LB2*  OAT  REL TRICSKOEFAUL TOATA , 10* NTH, MR*1. 
IF (~FILE*SIMU13* USEROIO) 

RETURN, OEF. 

ATTACH.OEF*  OATbCOTRICSKOEF AULTu ATA*IO*NT H*MR*1. 
COPTCR, OEF, SIMPLE. 

COPTCR.QEF, TABLES. 

ENOIF (USEROIO) 

IF  (-FILE.SINU13,  USEROIO) 

RE MI NO* SIMPLE* TABLES • 

RE  TURN,  TMPSMP,  TMPTA  B * TMPALL  *SIMU1 3. 

COMBINE* SIMPLEST MPS  HP, 10000. 

COMBINE, TABLES, T MPT AB* 10000. 

RE MI ND, TMPSMP, TMPTA B. 

CO PT CR* TMPSMP *TM PA. L. 

COPT CR»T MPT  AB*  TMPALL. 

RE  MI NO* TMPALL. 

COMBINE*TMPALL*SIMU 13* 10000. 

RE TURN, SIMPLE, TABLE S* TMPSMP* TMPTAB* TMPALL. 

ENOIF (USEROIO) 

REVERT. 

EX  IT*  S. 

BEGIN* ABORT  .PROFIL*  PROC=FILES. 

REVERT (ABORT) 


LOEXEC,*I*,  *L=,*B*,  *NAP=, 

•TABLES*, *MARN=,*LASTV«, 

•EXEC*  • 

RETURN,SINU21,SINU2  3. 

INPUTP  » SINU5=*I , SINU6**L*PARH,  T ABLES=*TA8LES ,MARN*  *MARN»  LASTV**LA  ST V 
RETJRNtZZZOUT. 

XF (FIlE, SINU39.N  039 ) 

RETURN. LG039. 

REMIND. SI HU39. 

FTN,I=SIMU39,A,  L*ZZZOUT ,R*2,B*LG039. 

ENOIF (N039) 

IF  (FILE,SINU21,N021  ) 

RETURN, LG021. 

REMIND, SINU21. 

FTN. I*SINU21 .A.  L*ZZZOUT ,R*2,B*LG021. 

ENOIF ( N021) 

IF  (FILE.SINU23.N023) 

RETURN, LG023. 

REMIND, SI MU 2 3. 

FTN,I=SIMU23,A,  L*ZZZOUT, R*2,B=LG023. 

ENOIF (N023) 

IFC(EQ.*EXEC.YES .NO  EXEC) 

RETURN, AMSS 

REMIND.LG021.LG023.LG039. 

RETURN, MAIN. 

COPY  BR,LG039,MAI N,2  • 

/♦  A03  BLOCK  DATA  RELOCATABLES  TO  MAIN  LOAO  FILE 
OUP,  2,*. 

C0PYBR»NDLB_$»MAIN» 10000. 

ENDUP. 

/* 

/•  ADO  OVERRIDE  BLOCK  DATAS  TO  MAIN  LOAO  FILE 
COPY  8R,LG021,NAIN,1  0000. 

COPT  BR,LG023, NAI N,1 0000 • 

✓ * 

IF  (FILE, LGO, QUICK) 

REMIND* LGO. 

copy  BR.LGO, NAI N,1 0000. 

ENOIF (QUICK) 

LOSET  (FILES  = GUPCRT) 

LDSET (USEP= SYSTENC) 

LOSET ,PRESETA*INOEF , NAP**NAP/NAPFILE) 

LOAO.NAIN. 

LOSET, LIB*SYSLI8. 

NOGO (AMSS  ) 

RETURN, NASTERL 
RETURN, TRICSL 
RETURN, VDLIB 
AMSS ,*L,PLS 10 0000. 

ENLIF (NOEXEC) 

RETURN, ZZZOUT. 
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RETURN.NAIN. 
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